Hello,
I am back.
Andreas, can I add something in stm32x_mass_erase() like
stm32x_read_options()
if (protected) : unlock + reset
continue with current code
/* unlock option flash registers */
target_write_u32(target, STM32_FLASH_KEYR, KEY1);
target_write_u32(target, STM32_FLASH_KEYR, KEY2);
Should I add a flag to mass_erase command to force or enable this
feature. Does this check must be done automatically ?
Thank you for your advise,
Gaëtan
On 06/01/2010 09:47 PM, Andreas Fritiofson wrote:
On Tue, Jun 1, 2010 at 1:56 PM, gcembed<[email protected]> 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
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
