should we drop mass_erase on programing hex list with stlink on nrf51

adafruit / Adafruit_Adalink

Python wrapper for Segger's J-Link Commander & STMicro STLink V2 to flash various ARM MCUs

MIT License

125 stars 33 forks source link

should we drop mass_erase on programing hex list with stlink on nrf51 #10

Open hathach opened 8 years ago

hathach commented 8 years ago

https://github.com/adafruit/Adafruit_Adalink/blob/master/adalink/cores/nrf51822.py#L68 force an mass erase on any hex program. Mass erase is indeed required for flashing Softdevice, however it is often in development that we only need to flash Application + signature. Maybe user should explicitly enter --wipe option when wanting to flash Softdevice.

I am not sure which is better, free fee to close this if this is not appropriate.

microbuilder commented 8 years ago

I think this might have been a problem with OpenOCD and the STLink ... from memory it only worked if you erased the chip first, but I could be mistaken since Tony did most of the work here. The JLink definitely doesn't have this requirement to erase first.

tdicola commented 8 years ago

Yeah I did run into some trouble with OpenOCD refusing to program unless the chip was erased. One thing I don't remember trying but found a little later is that the 'flash write_image' command has an optional erase parameter that will erase the memory before programming (can see description here http://openocd.org/doc/html/Flash-Commands.html). I haven't tried it but it might work here--let me try to take a look later this week to see if it works. Agreed that mass erase is kinda heavy handed to always require--if we can remove it and just erase what will be programmed then that would probably be best.

tdicola commented 8 years ago

Oh yeah I remember being a little scared by this part of the erase option in write_image:

"Warning: Be careful using the erase flag when the flash is holding data you want to preserve. Portions of the flash outside those described in the image’s sections might be erased with no notice.

When a section of the image being written does not fill out all the sectors it uses, the unwritten parts of those sectors are necessarily also erased, because sectors can’t be partially erased.
Data stored in sector "holes" between image sections are also affected. For example, "flash write_image erase ..." of an image with one byte at the beginning of a flash bank and one byte at the end erases the entire bank – not just the two sectors being written."

I think that's ok though assuming the sections we're programming are all contiguous and don't have important holes that we don't want to wipe too.

hathach commented 8 years ago

I am not sure if this helps, openocd has an helper (commnand ) script to ease the flash programming http://openocd.org/doc/html/Flash-Commands.html#program

Command: program filename [verify] [reset] [exit] [offset]
    This is a helper script that simplifies using OpenOCD as a standalone programmer. The only required parameter is filename, the others are optional.

It use flash write_image and can also verify image as well.

tdicola commented 8 years ago

Yeah that wrapper works great for programming one file and exiting, but from what I saw programming multiple files at a time was a little faster with explicit flash write_image commands and then an exit.

If neither of you guys see issues any concern if I swap over the logic for the nRF51822 to use flash write_image's erase command instead of using mass erase? I'll give it a test to see if I can update just the app code for example and leave the SD, etc. untouched. If it works then I can merge it in and drop the mass erase.

microbuilder commented 8 years ago

There are a number of use cases for the nRF51 and STM32F2 where we'll need to keep existing sections of flash intact, so I think trading off speed for flexibility is the right thing to do here.