Uploading sketch to Nano 33 BLE without erasing all of flash?

Is it possible to upload a sketch to the Nano 33 BLE without erasing all of flash? Just erase the pages that are used by the sketch. I want to use some of the flash as a block device for a LittleFileSystem, but it's a pain if I lose all the contents of it each time I upload a sketch.

I saw Ho to upload without erasing flash - eeprom memory which talks about the "Erase Flash" custom board option, but it doesn't look like that option is available for the Nano BLE. It looks like bossac is what actually uploads the sketch, and it's being passed the -e option to erase the entire flash. I tried removing that, but it fails before writing the first page with "Flash erase failed". And it does look like only eraseAll() is implemented, not erase() in the Arduino fork of bossac.

So it seems like this isn't possible? Is it a limitation of the bootloader that allows flashing over USB? Or of bossac's nrf52 support? Something else? Would using a standalone programmer be able to do what I want? I probably don't need to avoid erasing flash badly enough to buy a programmer, but I might if they don't cost too much. I haven't looked at the options for that yet; I'd like to know if it would even work first.

No.

Not unless you write your own boot loader and even then it is unlikely to do what you want.
The Nano 33 BLE has no EEPROM memory at all, so forget that.

Can you elaborate on that "no"? Obviously, the nRF52840 is able to erase the flash a 4K page at a time.

No way can you do this at all. What do you not understand about that?
Unless you write your own boot loader. What is so hard about understanding that?

So what has that got to do with a Nano 33 BLE processor?

Anyway to know what page it is possible to erase you need to know where things are stored and why you want to erase the sections you do.

You got your answer from me, so lets see is someone else comes along and disagrees with me.

This is a competitive forum and people are normally into disagreeing if they see something wrong.

No way can you do this at all. What do you not understand about that?

How do you know there's no way to do that? I was hoping for someone knowledgeable to explain
the details.

Unless you write your own boot loader. What is so hard about understanding that?

Nothing. I even mentioned that as a possibility in my original post: "Is it a limitation of the bootloader that allows flashing over USB?" And after a quick disassembly of the bootloader, it does seem that that's the case. I didn't spend much time looking into it, but as far as I can tell, flash_nrf_erase writes to the ERASEPAGE register in a loop, starting at some point until the end of the flash (presumably starting after the pages where the bootloader is stored).

    4e86:       f8c1 5508       str.w   r5, [r1, #1288] ; 0x508
    4e8a:       f7ff ffb1       bl      4df0 <nvmc_wait_ready>
    4e8e:       1a36            subs    r6, r6, r0
    4e90:       4405            add     r5, r0
    4e92:       d1f8            bne.n   4e86 <flash_nrf_erase+0x4e>

r0: page size, r5: address of page to be erased, r6: number of bytes to erase

But I then specifically asked about using a standalone programmer, which you completely ignored.

So what has that got to do with a Nano 33 BLE processor?

Sounds like you're not actually familiar with the Nano 33 BLE, in which case, I'm not sure why you're trying to answer my question. The nRF52840 is the processor that the Nano 33 BLE uses. https://docs.arduino.cc/hardware/nano-33-ble/ "The Arduino Nano 33 BLE shares its pinout with the classic Arduino Nano but builds on the nRF52840 microcontroller with 1MB CPU Flash Memory."

Anyway to know what page it is possible to erase you need to know where things are stored and why you want to erase the sections you do.

I know all of that. The bootloader is stored in the first page, page 0. My sketch ends at FLASHIAP_APP_ROM_END_ADDR, which is #defined in FlashIAP.h as

#define FLASHIAP_APP_ROM_END_ADDR std::max(std::max((uint32_t) __section_end(".rodata"), (uint32_t) __section_end(".text")), \
                                  (uint32_t) __section_end(".init_array"))

But that's actually only tangentially relevant to what I'm asking about. I don't really need to know that; the Arduino IDE/bossac is what needs to know it, and it does. Whenever it uploads a sketch, it says stuff like "Write 237624 bytes to flash (59 pages)". It obviously knows where to start writing, and how much to write. It just needs to be able to erase only the pages it writes, rather than everything after the bootloader.

lets see is someone else comes along and disagrees with me.

I'm already disagreeing with you, at least about your answer to my question as a whole. I do agree that due to limitations of the bootloader that the Nano BLE comes with, it's not possible to upload a sketch over the USB port without erasing the entire flash. However, it would be possible with a different bootloader that supported doing that. And after looking into it more, I'm pretty sure that it is also possible if I used an external programmer attached to the SWD pins.

So as far as I can tell, the answer to my question is: No, it's not currently possible to do that through the USB port, but it is possible with an external programmer via SWD.

I bought one of those Chinese nanoDAPs from eBay for $5, and can confirm that "Upload Using Programmer" does not erase the entire flash. I assume it only erases the portion that the sketch occupies.

and even then it is unlikely to do what you want.

I can also confirm that it does exactly what I want. My sketch creates a FlashIAPBlockDevice starting past the end of the area occupied by my sketch extending to the end of the flash. It then creates a LittleFileSystem on that device and stores files there. While the regular Upload through the USB port would cause the filesystem to be erased, Upload Using Programmer preserves the contents of the filesystem. I can upload revisions to my sketch without having to restore all the files that were stored on the flash.

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.