Bootloader drive is unstable and shows 10x more memory size

[Embedinno]

Describe the bug Hello, I want to apologize in advance if this is not the place or way to post something like this. If that's the case please guide me to the correct one.

I followed the instructions from the README file and setup my Linux environment with necessary tools to compile the bootloader code. After I run the command for compilation:

make BOARD=feather_nrf52840_express

I get the expected result:

LD feather_nrf52840_express_bootloader-0.3.2-184-g64ea299.out
   text    data     bss     dec     hex filename
  31364    1576   22618   55558    d906 _build/build-feather_nrf52840_express/feather_nrf52840_express_bootloader-0.3.2-184-g64ea299.out
Create feather_nrf52840_express_bootloader-0.3.2-184-g64ea299.hex
Create feather_nrf52840_express_bootloader-0.3.2-184-g64ea299-nosd.hex
Create feather_nrf52840_express_bootloader-0.3.2-184-g64ea299-nosd.uf2
Converting to uf2, output size: 72704, start address: 0x0
Wrote 72704 bytes to _build/build-feather_nrf52840_express/feather_nrf52840_express_bootloader-0.3.2-184-g64ea299-nosd.uf2
Create feather_nrf52840_express_bootloader-0.3.2-184-g64ea299_s140_6.1.1.hex
Zip created at _build/build-feather_nrf52840_express/feather_nrf52840_express_bootloader-0.3.2-184-g64ea299_s140_6.1.1.zip

The problem is, after I program the "feather_nrf52840_express_bootloader-0.3.2-184-g64ea299_s140_6.1.1.hex" hex file to a feather-sense board the behavior of the bootloader is unstable (breaks before the end of copy circuitpy uf2 file) with the error message. Another strange thing is that the size of the bootloader drive is not 3.87MB as it should be but it is showing as 31.8MB.

I must say that I am building the original feather_nrf52840_express srs files without any change.

I am using nRF prog on Win10 to program the new bootloader with Jlink and if I compare the hex file I built with the latest version of hex file you have in the releases - there are some differences in memory map that you will see down in the screenshots.

I would appreciate any assistance on this and I realize that this might not be a bug but that there is something that I am not doing right.

Set up

• Feather-Sense with nRF52840 and the original srs code from your github
• Win10 with Virtual Machine running Ubuntu 20.04.1

To Reproduce Steps to reproduce the behavior:

1. Install necessary apps via console as described in README
2. Build/compile the srs files for "feather_nrf52840_express" with command "make BOARD=feather_nrf52840_express"
3. Program the board with "feather_nrf52840_express_bootloader-0.3.2-184-g64ea299_s140_6.1.1.hex"
4. Unstable behavior and showing too much memory in bootloader drive

Expected behavior I would expect that usage of the built hex file is the same as the latest released file you have available on github under the name "feather_nrf52840_express_bootloader-0.3.2_s140_6.1.1.hex" which works great on the same hardware.

Screenshots

This is the memory map of official "feather_nrf52840_express_bootloader-0.3.2_s140_6.1.1.hex":

This is the normal operation of the same bootloader when programmed to the board:

This is the memory map of the bootloader I get after I build srs code for "feather_nrf52840_express":

This is the problematic operation of the bootloader I built - you can see that it shows too much memory:

And during the operation it is unstable and can not complete the transfer of circuitpy uf2 file:

Looking forward to your comments.

BR, Dusan

[hathach]

msc drive size is fake, 32MB is new feature. You should flash the feather_nrf5240_sense bootloader to feather sense board. Feather Express and Sense are 2 different boards.

[Embedinno]

msc drive size is fake, 32MB is new feature. You should flash the feather_nrf5240_sense bootloader to feather sense board. Feather Express and Sense are 2 different boards.

Hello and thanks you for your reply.

So the new (virtual) size of 32MB is normal.

As for the stability and performance I tried also with feather sense srs code with command:

make BOARD=feather_nrf52840_sense

and got a normal compilation:

CC dfu_ble_svc.c
CC main.c
CC flash_nrf5x.c
CC dfu_init.c
CC boards.c
CC pinconfig.c
CC nrfx_power.c
CC nrfx_nvmc.c
CC system_nrf52840.c
CC bootloader.c
CC bootloader_settings.c
CC bootloader_util.c
CC dfu_transport_serial.c
CC dfu_transport_ble.c
CC dfu_single_bank.c
CC ble_dfu.c
CC ble_dis.c
CC pstorage_raw.c
CC app_timer.c
CC app_scheduler.c
CC app_error.c
CC app_util_platform.c
CC crc16.c
CC hci_mem_pool.c
CC hci_slip.c
CC hci_transport.c
CC nrf_assert.c
CC usb_desc.c
CC usb.c
CC msc_uf2.c
CC ghostfat.c
CC dcd_nrf5x.c
CC tusb_fifo.c
CC usbd.c
CC usbd_control.c
CC cdc_device.c
CC msc_device.c
CC tusb.c
AS gcc_startup_nrf52840.S
LD feather_nrf52840_sense_bootloader-0.3.2-184-g64ea299.out
   text    data     bss     dec     hex filename
  31364    1576   22618   55558    d906 _build/build-feather_nrf52840_sense/feather_nrf52840_sense_bootloader-0.3.2-184-g64ea299.out
Create feather_nrf52840_sense_bootloader-0.3.2-184-g64ea299.hex
Create feather_nrf52840_sense_bootloader-0.3.2-184-g64ea299-nosd.hex
Create feather_nrf52840_sense_bootloader-0.3.2-184-g64ea299-nosd.uf2
Converting to uf2, output size: 72704, start address: 0x0
Wrote 72704 bytes to _build/build-feather_nrf52840_sense/feather_nrf52840_sense_bootloader-0.3.2-184-g64ea299-nosd.uf2
Create feather_nrf52840_sense_bootloader-0.3.2-184-g64ea299_s140_6.1.1.hex
Zip created at _build/build-feather_nrf52840_sense/feather_nrf52840_sense_bootloader-0.3.2-184-g64ea299_s140_6.1.1.zip

The resulting "feather_nrf52840_sense_bootloader-0.3.2-184-g64ea299_s140_6.1.1.hex" still has a difference in memory map compared to the released one "feather_nrf52840_sense_bootloader-0.3.2_s140_6.1.1.hex".

I programmed it to the board and after coping the circuitpy uf2 file I get the same error message before the end of copy as before. Please note that with released hex file I don't have this issue:

Is there a compilation settings that I am getting wrong or possibly some other issue?

Looking forward to your reply, Dusan

[hathach]

@Embedinno ah, this windows complain is pretty OK (but annoying), the nrf complete dfu and reset to fast and didn't answer windows last scsi command. The DFU should be flawless and the circuitpython should start without issue. This issue is fixed in tinyusb stack https://github.com/hathach/tinyusb/pull/562 . Thanks for reporting the issue, I will update the usb stack fix and test with this soon enough.

[Embedinno]

@hathach Excellent, I will follow this up and test as soon as update is available.

Do you have any info on the difference in memory map (the application section that appears in the build hex file while not in the released hex)?

The following image shows the memory map of the built hex on the right, and the memory map of the chip on the left after this bootloader is programmed and circuitpy is loaded:

If I do the same with released bootloader I get this:

Thanks, Dusan

[hathach]

flash target only flash the bootloader, you need to explicitly flash the sd with sd target. It is mentioned in the readme.md

[Embedinno]

flash target only flash the bootloader, you need to explicitly flash the sd with sd target. It is mentioned in the readme.md

Hello, thanks for continuing support.

For what I understand this is the procedure of flashing bootloader and SD in two separate steps and via console. I just gave it a try and I got the same resulting memory map as I did before when I was programming bootloader and SD in one step via nRF prog application in Windows.

The difference between memory map of the released bootloader hex file and the one I got after building srs code remains.

Looking forward to your comments, Dusan

[hathach]

Ok, I am confused, what is wrong with the current memory map of the bootloader merged hex again ? Maybe I didn't get the question right !

PS: Also please resize your screenshot for next upload, it is a bit too big

[Embedinno]

Ok, I am confused, what is wrong with the current memory map of the bootloader merged hex again ?

This is the memory map of the released bootloader hex file - address range is 0x000F4000 to 0x000FB797 without anything else above bootloader segment:

On the other hand this is the memory map of the built bootloader hex file - address range is 0x000F4000 to 0x000FC04B with some additional block (which doesn't exist in released version) in address range 0x000FD800 to 0x000FD857:

The thing is I don't know what's causing this difference between the released and built version of bootloader and if it could lead to some issues or not.

Thanks, Dusan

[hathach]

it is probably cf2 or pinconfig, unless there is any issues I don't think there is any reason to worry about.

[Embedinno]

it is probably cf2 or pinconfig, unless there is any issues I don't think there is any reason to worry about.

Thanks.

@Embedinno ah, this windows complain is pretty OK (but annoying), the nrf complete dfu and reset to fast and didn't answer windows last scsi command. The DFU should be flawless and the circuitpython should start without issue. This issue is fixed in tinyusb stack hathach/tinyusb#562 . Thanks for reporting the issue, I will update the usb stack fix and test with this soon enough.

Let me know as soon as update is available, would like to help with the test if needed.

All the best, Dusan

[dhalbert]

I think this might be what was noticed here: https://forums.adafruit.com/viewtopic.php?f=60&t=172649

[deadprogram]

I think I am having the same issue in Ubuntu 18.04 with an ItsyBitsy-nRF52840 using the 0.3.2 firmware.

After flashing by copying a UF2 file to the drive, there is an error seeming due to the same cause. Here is an excerpt from my dmesg log:

Here is where the board is initially mounted:

[ 7093.222994] usb 1-4.4.4.1: new full-speed USB device number 51 using xhci_hcd
[ 7093.374620] usb 1-4.4.4.1: New USB device found, idVendor=239a, idProduct=0051, bcdDevice= 1.00
[ 7093.374629] usb 1-4.4.4.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 7093.374635] usb 1-4.4.4.1: Product: ItsyBitsy nRF52840 Express
[ 7093.374639] usb 1-4.4.4.1: Manufacturer: Adafruit Industries
[ 7093.374644] usb 1-4.4.4.1: SerialNumber: A4BC3754A0868EBA
[ 7093.396174] cdc_acm 1-4.4.4.1:1.0: ttyACM7: USB ACM device
[ 7093.397385] usb-storage 1-4.4.4.1:1.2: USB Mass Storage device detected
[ 7093.398305] scsi host4: usb-storage 1-4.4.4.1:1.2
[ 7094.412260] scsi host4: scsi scan: INQUIRY result too short (5), using 36
[ 7094.412276] scsi 4:0:0:0: Direct-Access     Adafruit nRF UF2          1.0  PQ: 0 ANSI: 2
[ 7094.413239] sd 4:0:0:0: Attached scsi generic sg2 type 0
[ 7094.413892] sd 4:0:0:0: [sdc] 8000 512-byte logical blocks: (4.10 MB/3.91 MiB)
[ 7094.414258] sd 4:0:0:0: [sdc] Write Protect is off
[ 7094.414265] sd 4:0:0:0: [sdc] Mode Sense: 03 00 00 00
[ 7094.414546] sd 4:0:0:0: [sdc] No Caching mode page found
[ 7094.414556] sd 4:0:0:0: [sdc] Assuming drive cache: write through
[ 7094.440268]  sdc:
[ 7094.442523] sd 4:0:0:0: [sdc] Attached SCSI removable disk

And here is when the UF2 file is copied:

[ 7096.651291] usb 1-4.4.4.1: device firmware changed
[ 7096.652207] usb 1-4.4.4.1: USB disconnect, device number 51
[ 7096.666922] blk_update_request: I/O error, dev sdc, sector 65 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0
[ 7096.666935] Buffer I/O error on dev sdc, logical block 65, lost sync page write
[ 7096.694998] FAT-fs (sdc): unable to read boot sector to mark fs as dirty

Any thoughts? Thanks in advance.

[deadprogram]

One additional note: once this error has occurred, you must perform a hard reset of the board by pressing the button, and then it boots normally into the application.

[hathach]

@deadprogram does the bootloader successfully update the new application ? If yes, then it is just the minor complain as mentioned above.

[deadprogram]

For us it is a problem because we want to update the application firmware remotely, and cannot push the reset button due to being part of an automated process.

[hathach]

This issue should already be fixed with latest release