On Tue, Jun 1, 2010 at 1:56 PM, gcembed <gcem...@gmail.com> wrote:
> Hello,
> I have added a new command for stm32x : mass_erase_unlock
> This function combine "stm32x unlock 0" + reset to apply unlock + "stm32x
> mass_erase 0"
> In this way, it is more easier to handle the unlock sequence and makes the
> (annoying) reset procedure transparent.
> After calling mass_erase_unlock, flash write_image can immediately  called.
> Here is an example of my flashing procedure :
>
> init
> jtag_khz 1000
> reset_config trst_and_srst
> halt
> flash probe 0
> flash protect 0 0 last off
> stm32x mass_erase_unlock 0
> flash write_bank 0 file.bin 0
> flash protect 0 0 last on
> verify_image file.bin 0
>
> Thanks
> Gaëtan

I like the idea, it would be very convenient to have a single command
to always put the chip in a well defined, cleared state. Perfect for
programming scripts, which today need to assume that the flash is
locked. However...

If the flash is locked, the unlock procedure will perform a mass
erase, so the second mass erase will just waste time and flash erase
cycles. Plus, the SP and PC could have different values after the
procedure depending on whether the protection was active or not (see
the test I posted yesterday). I would prefer something like the
following pseudo code to get a consistent state with minimum number of
operations.

read option byte;
if (readout protection active)
   unlock;
else
   mass_erase;
reset;

Then one starts to think why we need this new command in addition to
the separate unlock and mass_erase commands. Unlock already implies
mass_erase. And is there ever a reason to (try to) do a mass_erase on
a locked flash without wanting to unlock it? Or to mass_erase or
unlock without resetting the core afterwards (how about when running
from ram?). The operations seem to go hand in hand. Maybe we only need
one command to do it all.

/Andreas
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to