sample fat_fs

[TF mulder]

Hi,

I'm trying the  sample fat_fs  on the nRF5340 DK

1) It does build, but there is awarning

CMake Warning at D:\nRfConnect\v1.8.0\zephyr\CMakeLists.txt:722 (message):
No SOURCES given to Zephyr library: drivers__disk

2) looked with the debugger: in the main() it reaches the  LOG_ERR("Storage init ERROR!");

void main(void)

if (disk_access_init(disk_pdrv) != 0) {

LOG_ERR("Storage init ERROR!");

 

Could you please comment on the above 2 points ?

What steps should i make to have a SD-card running,  is using sample fat_fs the way to go ?

Best Regards,

Theo

[TF mulder]

Hi Simon,

Thanks for the help.

i added  nrf5340dk_nrf5340_cpuapp.overlay   with the same content as nrf52840_blip.overlay

(added in VisualStudioCode  at input files,  the tool places the file   nrf5340dk_nrf5340_cpuapp.overlay  in the  fat_fs-directory, not in the fat_fs/boards directory)

i placed the same content from nrf52840_blip.overlay   into the  nrf5340dk_nrf5340_cpuapp.overlay

it showed 2 problems:   wiggle-line under &spi1  and a wiggle-line under sdhc@0

I altered &spi1 into &spi2   now the 2 problems where gone.  so did a prestine-build, and looked in the zephyr.dts

in there i found:

spi2: spi@b000 {
#address-cells = < 0x1 >;
#size-cells = < 0x0 >;
reg = < 0xb000 0x1000 >;
interrupts = < 0xb 0x1 >;
status = "okay";
label = "SPI_2";
compatible = "nordic,nrf-spim";
sck-pin = < 0x2f >;
miso-pin = < 0x2e >;
mosi-pin = < 0x2d >;
cs-gpios = < &gpio0 0x11 0x0 >;
sdhc0: sdhc@0 {
compatible = "zephyr,mmc-spi-slot";
reg = < 0x0 >;
status = "okay";
label = "SDHC0";
spi-max-frequency = < 0x16e3600 >;
};

So now the pins ..   does sck-pin <0x2f> means   47 -> 47-32=15   so P1.15    correct??   (and so on for 0x2e, 0x2d)

in the nrf5340 dk schematic i find   p1.15  on GPIO_IF2 D13  ... so ok 

But now the cs-gpios   &gpio0 0x11 0x0        does this mean gpio0   -> P0.00    or  0x11->17-> P0.17  

P0.00 would be OK  (GPIO_IF3 / d14)   but  P0.17 is QSPI_clk (SB21)  so ocuppied.

i will try  to connect a sd-card on the pins  P1.15, P1.14, P1.13   and the CS on P0.00  ..

Then bonus question:  could i alter the pins to different location?, how is that being done in the software ?

Looking forward on your comments Simon,  thanks.

Best Regards,

Theo

[TF mulder]

Hi Simon,

Thanks again for the valuable info.  (definitely more studying on my side :-)

I connected all  and using p0.17 for the cs., and double, double checked.

unfortunately, no cigar.., still not working..   it still hits the LOG_ERR("Storage init ERROR!");  (as with my original question 2) )

maybe relevant to mention .. ??

in de 'input-files'  there are a few problems signaled:

-in the file 'nrf5340dk_nrf5340_cpuapp.dts'  a wiggle-line (at line-13)   compatible = "nordic,nrf5340-dk-nrf5340-cpuapp";

-in the file ''nrf5340_cpuapp_qkaa.dtst 3-wigglles (at line 24)

compatible = "nordic,nRF5340-CPUAPP-QKAA", "nordic,nRF5340-CPUAPP", "nordic,nRF53", "simple-bus";

 wiggles under all exept "simple-bus".

--

then to be sure the connections i made to the sd-card  ( im using: https://www.sparkfun.com/products/544 )

p1.15  connected to 'sck'

p1.14 connected to 'DO'

p1.13 connected to 'DI'

p0.17 connected to 'CS'

vdd   connected to 'VCC'

gnd connected to 'GND'

Please your comments again.. (lets nail this :-)

Best Regards,

Theo

[TF mulder]

Hi Simon,

I tried again..   the warning

CMake Warning at D:\nRfConnect\v1.9.0\zephyr\CMakeLists.txt:764 (message):
No SOURCES given to Zephyr library: drivers__disk

is now gone..

My mistake sorry

but i do not see the  cs-gpios  signal in the Device Tree/ GPIO

Best Regards,

Theo

PS: i will go and check if i get signals ??

[TF mulder]

When i have nothing in the nrf5340dk_nfr5340_cpuapp.overlay .. THEN i get the  

CMake Warning at D:\nRfConnect\v1.9.0\zephyr\CMakeLists.txt:764 (message):
No SOURCES given to Zephyr library: drivers__disk

back again. 

[Simon]

Do you use NCS v1.9.0 now? Earlier I saw the path "D:\nRfConnect\v1.8.0", now I see the path "D:\nRfConnect\v1.9.0", please inform me of the NCS version you're using.

Try going into the folder <ncs location>/nrf and run git describe --tags.

TF mulder said:

One point i noticed:  in the Device Tree/ GPIO  there i could not find the  cs-gpios, while the 3-Spi signals can be seen in that list.

TF mulder said:

this is still there:  

CMake Warning at D:\nRfConnect\v1.9.0\zephyr\CMakeLists.txt:764 (message):
No SOURCES given to Zephyr library: drivers__disk

I added an overlay file and  these two configs to the prj.conf and built, and I could indeed see the cs-gpios under spi2 in fat_fs/build/zephyr/zephyr.dts

fat_fs_modified.zip

When building this sample using  west build -b nrf5340dk_nrf5340_cpuapp -d build_53 -p in NCS v1.9.0, I did not get any "No SOURCES given to Zephyr library: drivers__disk", check the build output below

 west build -b nrf5340dk_nrf5340_cpuapp -d build_53 -p
-- west build: generating a build system
Including boilerplate (Zephyr base): C:/v1.8.0/zephyr/cmake/app/boilerplate.cmake
-- Application: C:/v1.8.0/zephyr/samples/subsys/fs/fat_fs
-- Using NCS Toolchain 1.9.0 for building. (C:/v1.9.0/toolchain/cmake)
-- Zephyr version: 2.7.99 (C:/v1.8.0/zephyr), build: v2.7.99-ncs1
-- Found Python3: C:/v1.9.0/toolchain/opt/bin/python.exe (found suitable exact version "3.8.2") found components: Interpreter 
-- Found west (found suitable version "0.12.0", minimum required is "0.7.1")
-- Board: nrf5340dk_nrf5340_cpuapp
-- Cache files will be written to: C:/v1.8.0/zephyr/.cache
-- Found dtc: C:/v1.9.0/toolchain/opt/bin/dtc.exe (found suitable version "1.4.7", minimum required is "1.4.6")
-- Found toolchain: gnuarmemb (C:/v1.9.0/toolchain/opt)
-- Found BOARD.dts: C:/v1.8.0/zephyr/boards/arm/nrf5340dk_nrf5340/nrf5340dk_nrf5340_cpuapp.dts
-- Found devicetree overlay: C:/v1.8.0/zephyr/samples/subsys/fs/fat_fs/boards/nrf5340dk_nrf5340_cpuapp.overlay
-- Generated zephyr.dts: C:/v1.8.0/zephyr/samples/subsys/fs/fat_fs/build_53/zephyr/zephyr.dts
-- Generated devicetree_unfixed.h: C:/v1.8.0/zephyr/samples/subsys/fs/fat_fs/build_53/zephyr/include/generated/devicetree_unfixed.h
-- Generated device_extern.h: C:/v1.8.0/zephyr/samples/subsys/fs/fat_fs/build_53/zephyr/include/generated/device_extern.h
-- Including generated dts.cmake file: C:/v1.8.0/zephyr/samples/subsys/fs/fat_fs/build_53/zephyr/dts.cmake
Parsing C:/v1.8.0/zephyr/Kconfig
Loaded configuration 'C:/v1.8.0/zephyr/boards/arm/nrf5340dk_nrf5340/nrf5340dk_nrf5340_cpuapp_defconfig'
Merged configuration 'C:/v1.8.0/zephyr/samples/subsys/fs/fat_fs/prj.conf'
Configuration saved to 'C:/v1.8.0/zephyr/samples/subsys/fs/fat_fs/build_53/zephyr/.config'
Kconfig header saved to 'C:/v1.8.0/zephyr/samples/subsys/fs/fat_fs/build_53/zephyr/include/generated/autoconf.h'
-- The C compiler identification is GNU 9.2.1
-- The CXX compiler identification is GNU 9.2.1
-- The ASM compiler identification is GNU
-- Found assembler: C:/v1.9.0/toolchain/opt/bin/arm-none-eabi-gcc.exe
-- Configuring done
-- Generating done
-- Build files have been written to: C:/v1.8.0/zephyr/samples/subsys/fs/fat_fs/build_53
-- west build: building application
[169/179] Linking C executable zephyr\zephyr_pre0.elf

[173/179] Linking C executable zephyr\zephyr_pre1.elf

[179/179] Linking C executable zephyr\zephyr.elf
Memory region         Used Size  Region Size  %age Used
           FLASH:       49284 B         1 MB      4.70%
            SRAM:       10792 B       448 KB      2.35%
        IDT_LIST:          0 GB         2 KB      0.00%

When I removed  these two configs I did get the warning however

west build -b nrf5340dk_nrf5340_cpuapp -d build_53 -p
-- west build: making build dir C:\v1.8.0\zephyr\samples\subsys\fs\fat_fs\build_53 pristine
-- west build: generating a build system
Including boilerplate (Zephyr base): C:/v1.8.0/zephyr/cmake/app/boilerplate.cmake
-- Application: C:/v1.8.0/zephyr/samples/subsys/fs/fat_fs
-- Using NCS Toolchain 1.9.0 for building. (C:/v1.9.0/toolchain/cmake)
-- Zephyr version: 2.7.99 (C:/v1.8.0/zephyr), build: v2.7.99-ncs1
-- Found Python3: C:/v1.9.0/toolchain/opt/bin/python.exe (found suitable exact version "3.8.2") found components: Interpreter 
-- Found west (found suitable version "0.12.0", minimum required is "0.7.1")
-- Board: nrf5340dk_nrf5340_cpuapp
-- Cache files will be written to: C:/v1.8.0/zephyr/.cache
-- Found dtc: C:/v1.9.0/toolchain/opt/bin/dtc.exe (found suitable version "1.4.7", minimum required is "1.4.6")
-- Found toolchain: gnuarmemb (C:/v1.9.0/toolchain/opt)
-- Found BOARD.dts: C:/v1.8.0/zephyr/boards/arm/nrf5340dk_nrf5340/nrf5340dk_nrf5340_cpuapp.dts
-- Found devicetree overlay: C:/v1.8.0/zephyr/samples/subsys/fs/fat_fs/boards/nrf5340dk_nrf5340_cpuapp.overlay
-- Generated zephyr.dts: C:/v1.8.0/zephyr/samples/subsys/fs/fat_fs/build_53/zephyr/zephyr.dts
-- Generated devicetree_unfixed.h: C:/v1.8.0/zephyr/samples/subsys/fs/fat_fs/build_53/zephyr/include/generated/devicetree_unfixed.h
-- Generated device_extern.h: C:/v1.8.0/zephyr/samples/subsys/fs/fat_fs/build_53/zephyr/include/generated/device_extern.h
-- Including generated dts.cmake file: C:/v1.8.0/zephyr/samples/subsys/fs/fat_fs/build_53/zephyr/dts.cmake
Parsing C:/v1.8.0/zephyr/Kconfig
Loaded configuration 'C:/v1.8.0/zephyr/boards/arm/nrf5340dk_nrf5340/nrf5340dk_nrf5340_cpuapp_defconfig'
Merged configuration 'C:/v1.8.0/zephyr/samples/subsys/fs/fat_fs/prj.conf'
Configuration saved to 'C:/v1.8.0/zephyr/samples/subsys/fs/fat_fs/build_53/zephyr/.config'
Kconfig header saved to 'C:/v1.8.0/zephyr/samples/subsys/fs/fat_fs/build_53/zephyr/include/generated/autoconf.h'
-- The C compiler identification is GNU 9.2.1
-- The CXX compiler identification is GNU 9.2.1
-- The ASM compiler identification is GNU
-- Found assembler: C:/v1.9.0/toolchain/opt/bin/arm-none-eabi-gcc.exe
CMake Warning at ../../../../CMakeLists.txt:764 (message):
  No SOURCES given to Zephyr library: drivers__disk

  Excluding target from build.


-- Configuring done
-- Generating done
-- Build files have been written to: C:/v1.8.0/zephyr/samples/subsys/fs/fat_fs/build_53
-- west build: building application
[164/174] Linking C executable zephyr\zephyr_pre0.elf

[168/174] Linking C executable zephyr\zephyr_pre1.elf

[174/174] Linking C executable zephyr\zephyr.elf
Memory region         Used Size  Region Size  %age Used
           FLASH:       42664 B         1 MB      4.07%
            SRAM:       10608 B       448 KB      2.31%
        IDT_LIST:          0 GB         2 KB      0.00%

TF mulder said:

PS: i will go and check if i get signals ??

Yes, try that.

If you still experience that disk_access_init(disk_pdrv) causes "Storage init ERROR!" to get printed, it means that the function returns an error (a non-null value). To get to the bottom of that you should try to debug the application and the call stack of disk_access_init and find the exact line that returns the error. Here is the call stack:

• First disk_access_init(disk_pdrv) is called in fat_fs/main.c
• This function can be found in zephyr/subsys/disk/disk_access.c
• Nex disk->ops->init(disk) will get called
• The init function should be mapped to disk_spi_sdhc_access_init(), because you're using the comatible "zephyr,mmc-spi-slot" in the overlay, which will map it to sdmmc_spi.c
• disk_spi_sdhc_access_init() will then call sdhc_spi_detect()
• The function  sdhc_spi_detect() will try to communicate with the SD card, and might lead to a non-null error at many places:
  • sdhc_spi_go_idle()
  • sdhc_retry_ok()
  • sdhc_spi_cmd_r1_idle()
  • sdhc_spi_cmd_r1()
  • /* Card never exited idle */
  • ...and many more

Try to debug your program (set CONFIG_DEBUG_OPTIMIZATIONS=y in the prj.conf and follow the Segger Ozone guide or nRF Connect for VS Code, 5: Debugging) to figure out where in the call stack above a non-null error is returned.

Best regards,

Simon

[TF mulder]

Hi Simon,

yes, is correct i saw a presence of 1.9 now, so i thought give that a try. (but responded the same)

==>   i had a resonce of the card.. by putting the CS-pin on the SdCard to GND.  But i saw the respononse only once..(not any more)    ==>The signal cs-gpios i can not find..

Maybe  this need attention, ==> where is the  cs-gpios going.

(ofcause i will study and try your long and  complicated(at least to me;-) response)

Regards,

Theo

[Simon]

If you don't figure it out I will try to get ahold of an SD card reader, so I can actually run and debug the program myself.

[TF mulder]

When i switch off the power of the board, and then connect the CS of the card to the GND,  and power up the board, the the sc-card gives a response !!    When after that i deconnect the cs from the GND and push reset then it does not respond(errors). as te be expected. When i then connect the CS to the ground again and give the board a reset, then it does not respond(Errors).   

So only after putting the board power OFF, then on (with the CS   to GND) then the sd-card response.

So where is the cs-gpios going to ??

[TF mulder]

Hi Simon,

I would like to let you know:  i have now managed to write some data to the SD-card and read it back.

using disk_access_write(),  disk_access_read()

I will add a seperate gpio-pin to be used as CS for the SdCard.

==>  but actualy the question:  cs-gpios going to ??   would be nice to know..,  how, that could/should be resolved.  (But now at least im not blocked by this issue)

To have writing a file onto the SD-CARD, that a PC will understand needs some more then 

disk_access_write(),  disk_access_read()  Correct?

What do i need to look into to have data to be written onto the SD-card? , such that the PC doe understand.

Thanks  Simon for the help.

I'm looking forward to your reply

Best Regards,

Theo

[Simon]

Ah, I'm really sorry for not seeing this earlier. Try using another pin than P0.17 for CS. If you take a look at nRF5340 DK Hardware --> External memory you can see that P0.17 is connected to SCLK of the nRF5340DK onboard flash (to use it, you must cut SB11 and short SB21). Try to use another pin like P1.12 for CS.

If you turn the nRF5340 DK upside down, you can see the GPIOs that are occupied by onboard functionality.

Best regards,

Simon

[TF mulder]

Hi Simon,

Thanks..

I did change the pin number before.., but just checked again,

this time (i tried manny more pins before),   i used cs-gpios = <&gpio0 10 GPIO_ACTIVE_LOW>;

But the P0.10 pin is just not active its floating.

And in the (Visual Studio Code) under DeviceTree/Gpio  neither &gpio0, nor &gpio0 is showing any signal that could reate to  cs-gpios.

Best Regards,

Theo

[TF mulder]

Hi Simon,

Got It now :-)

I was looking how to control GPIO pins in general, and came across this tiket:

https://devzone.nordicsemi.com/f/nordic-q-a/67320/unsupported-pin-error-when-using-pins-on-port-1-of-the-nrf52840dongle/275624#275624

Now i added in the fat_fs sample:  main.c file

gpio0dev = device_get_binding("GPIO_0");

And behold... the    cs-gpios  on P0.10  is now working !!

But still ... in the (Visual Studio Code) under DeviceTree/Gpio  neither &gpio0, nor &gpio0 is showing any signal that could relate to  cs-gpios

Thanks Simon for all the help.

Remains this (new)question:   

To have writing a file onto the SD-CARD, that a PC will understand needs some more then 

disk_access_write(),  disk_access_read()  Correct?

What do i need to look into,  to have data to be written onto the SD-card? , such that the PC does understand.

Best Regards,

Theo