Log to nrf52 thingy internal flash

[spoerk]

I am working on a prototype using the nRF Connect SDK v2.1.0 on the nRF52 Thingy platform.

For my prototype, I need to store normal log output on the internal flash of the nRF52 Thingy in FAT format. The reason behind this is: I will put my Thingys in a testing environment to collect data. After some days, I want to collect the Thingys and read the log data via USB.

What is the best way to implement that?

I have been trying the https://docs.zephyrproject.org/latest/samples/subsys/usb/mass/README.html#fat-fs-example, but the FLASH configuration does not work (not on the Thingy and not on the nRF52840DK platform).

Best regards,

Michael

[Simon]

Hello Michael

I tried running buildining the sample \zephyr\samples\subsys\usb\mass in NCS v2.1.0 and flashing it to the nRF52840DK v3.0.0 but did not encounter the issue you did.

I got the following RTT output:

[00:00:00.255,645] <inf> main: No file system selected
[00:00:00.255,737] <inf> main: The device is put in USB mass storage mode.

and the following serial output:

*** Booting Zephyr OS build v3.1.99-ncs1  ***
[00:00:00.255,645] <inf> main: No file system selected
[00:00:00.255,737] <inf> main: The device is put in USB mass storage mode.

Try running nrfjprog --qspieraseall first, and program the USB Mass sample again.

Best regards,

Simon

[spoerk]

Hi Simon, 

Thank you for your fast reply. As far as I can tell, you run the sample without specifying a file system. ("No file system selected" in the RTT output.

Here is my full prj.conf content:

CONFIG_STDOUT_CONSOLE=y

#USB related configs
CONFIG_USB_DEVICE_STACK=y
CONFIG_USB_DEVICE_PRODUCT="Zephyr MSC sample"
CONFIG_LOG=y
CONFIG_USB_DRIVER_LOG_LEVEL_ERR=y
CONFIG_USB_MASS_STORAGE=y
CONFIG_USB_DEVICE_LOG_LEVEL_ERR=y
CONFIG_USB_MASS_STORAGE_LOG_LEVEL_ERR=y

CONFIG_MAIN_STACK_SIZE=1536

CONFIG_APP_MSC_STORAGE_FLASH_FATFS=y

I have executed nrfjprog --qspieraseall, but it did not solve the problem.

Best regards,

Michael

[Simon]

Can you try to apply the following patch to Zephyr?

diff --git a/drivers/disk/flashdisk.c b/drivers/disk/flashdisk.c
index 62ad2babeb..3917900779 100644
--- a/drivers/disk/flashdisk.c
+++ b/drivers/disk/flashdisk.c
@@ -56,8 +56,11 @@ static int disk_flash_access_init(struct disk_info *disk)
 		return 0;
 	}
 
-	flash_dev = device_get_binding(CONFIG_DISK_FLASH_DEV_NAME);
-	if (!flash_dev) {
+	//flash_dev = device_get_binding(CONFIG_DISK_FLASH_DEV_NAME);
+	//if (!flash_dev) {
+	flash_dev = DEVICE_DT_GET(DT_NODELABEL(mx25r64));
+    if (!device_is_ready(flash_dev)) {
 		return -ENODEV;
 	}

After I did that, I got the following output using the USB mass sample with your prj.conf.

*** Booting Zephyr OS build v3.1.99-ncs1  ***
Area 4 at 0x0 on mx25r6435f@0 for 131072 bytes
Mount /NAND:: 0
/NAND:: bsize = 512 ; frsize = 512 ; blocks = 216 ; bfree = 216
/NAND: opendir: 0
End of files
[00:00:05.844,879] <inf> main: The device is put in USB mass storage mode.

Use of the devicetree label property has been deprecated per release notes of Zephyr v.3.2, and the flashdisk driver has not taken this into account.

Would you be able to create a Zephyr GitHub issue about this?

Best regards,

[spoerk]

Thanks that fixed the problem.

I have created a Zephyr issue so that this will get fixed in the future (https://github.com/zephyrproject-rtos/zephyr/issues/51720). Thanks.

[spoerk]

Do you by any chance know, how to configure the Zephyr FAT FS so that I can mount it on Windows without needing to format it?

With your fix, I am able to mount it, but I think the config is wrong. When I format it in Zephyr, Windows cannot read it. When I format it in Windows, Zephyr cannot read it.

I could not find anything about FAT configuration for Windows compatibility in this forum.

All the best,

Michael

[Sigurd Hellesvik]

Hi Michael,

I know windows has a limited set of supported filesystem formats.
My best guess is that you will need to figure out if windows supports FAT at all, and then what specific settings windows needs for FAT.

I do not think we have anything on this, but I can try to look a bit more into it in the next couple of days.

Regards,
Sigurd Hellesvik