SD Card Issues after updating to SDK 2.1

[maluJ]

We have updated our firmware runnung on an nRF9160 from SDK 1.9 to SDK 2.1 using the now deprecated SPM (We will upgrade to TFM soon). 

When booting our firmware, we initialize and mount our SD Card using FAT filesystem. 

The function disk_access_get_di couldnt find any disk  (returned null) so after some research in this forum and on github we updated our devicetree as following:

NOTE: we had to define sck-pin, mosi-pin and miso-pin in order to make it work. 

And activated to following additional kConfig:

Now, disk_access_get_di found our sd card, but it crashed (immediate reset) at the following line:

SD Card initilization happens during initialization level 'POST_KERNEL'. We had to change this to 'APPLICATION' to make it work...

SYS_INIT(initSdCard, APPLICATION, CONFIG_SDHC_INIT_PRIORITY);

We try to understand if this is to be expected or a bug? What is the problem of running this on initialization level 'POST_KERNEL'? Also, could you update the samples? We think its outdated.. https://github.com/nrfconnect/sdk-zephyr/tree/v3.1.99-ncs1-branch/samples/subsys/fs/fat_fs 

[Stian Røed Hafskjold]

Hi Manuel,

Looks like the problem with using POST_KERNEL initialization level is the fatfs_init() in subsys/fs/fat_fs.c, which is initialized at APPLICATION priority 40: https://github.com/nrfconnect/sdk-zephyr/blob/86893246053c50d34618f09ec6722cae8ba19472/subsys/fs/fat_fs.c#L490

Not exactly sure what your application looks like, but if we assume that it is a copy of the samples/subsys/fs/fat_fs, and that you moved the SD card and FAT FS initialization steps out of main() into a function initSdCard() which is registered during boot with SYS_INIT(initSdCard, POST_KERNEL, CONFIG_SDHC_INIT_PRIORITY); then the init steps should work all the way until fs_mount() because the fat_fs init has not started yet.

The relevant drivers are initialized in this order:

• https://github.com/nrfconnect/sdk-zephyr/blob/86893246053c50d34618f09ec6722cae8ba19472/drivers/spi/spi_nrfx_spim.c#L606
• https://github.com/nrfconnect/sdk-zephyr/blob/86893246053c50d34618f09ec6722cae8ba19472/drivers/sdhc/sdhc_spi.c#L756
• https://github.com/nrfconnect/sdk-zephyr/blob/86893246053c50d34618f09ec6722cae8ba19472/drivers/disk/sdmmc_subsys.c#L137

Last one at POST_KERNEL 90. It could be a possibility to initialize FATFS POST_KERNEL > 90, and then your initSdCard funciton at POST_KERNEL after FATFS, but I'm not sure if this will brake compatibility with other modules. Anyways, I tested it here and it seems to work fine with at least the samples/subsys/fs/fat_fs sample. Not sure if this is concidered a bug or not, but I will report it internally.

Regarding the fs_close() issue, it looks to me like an issue with how the filesystem synchronization is implemented in the FATFS module, which checks if there is no pending write. It will return FR_DISK_ERR as long as the return error is not 0. The disk_ioctl call, however, returns -ENOSYS (not implemented). I believe this is because this feature is not relevant when using SD card with SPI interface.

This is of course a bug, and I have reported it to the SDK team. A temporary workaround could be to just comment out the check in ff.c that I linked to above. Or let z_impl_sdhc_card_busy return 0 instead of -ENOSYS.

Best regards,
Stian

[maluJ]

Thanks for this elaborative answer Stian! 

We already adapted our application to run the sd card initialization at APPLICATION level, which work fine.

But very helpful to understand that POST_KERNEL > 90 should be possible too. 

Regarding 'fs_close()' --> We implemented the workaround on our own sdk-zephyr fork as you suggested and it works fine. Could you let me know once the fix is backported to the NRF SDK zephyr fork or whats the best way to know when it is fixed?

Thanks alot for the help again. 

[Stian Røed Hafskjold]

Hi, no problem! Not sure if there are any other ways of knowing if it has been fixed than checking the tagged release, when a new release is notified. Anyways, I will let you know through this ticket.

Regards,
Stian

[Stian Røed Hafskjold]

The issue has already been fixed and is now part of the main branch: https://github.com/nrfconnect/sdk-zephyr/commit/2c2b8c342247ff767ee369169a74dbcf09b5edc6

I'm not sure if it has made it into the next NCS tagged release, as it was merged after the commit pointed to by the development branch.