About Andrew Watson

Andrew Watson · 2018-03-20

Posted on March 20, 2018 at 08:55Hello,I've encountered a systematic problem with the STM32L151 which I'm finding hard to debug.We write a bootloader and main image to the flash memory using the ST-Link CLI, and at the same time write some individua...

Andrew Watson · 2017-05-12

Posted on May 12, 2017 at 11:02I've noticed this behaviour in Atollic TrueStudio 7.0.1 and 7.1.2, using the ST-Link V2 debugger (several variants, including the regular ST-Link V2 and the ISOL version). When I place a breakpoint in the code, the exe...

Andrew Watson · 2014-07-28

Posted on July 28, 2014 at 15:07Hello,We're currently using the ST-Link Utility CLI to program small production batches. We need to program some individual configuration bytes for each device, which we write to the EEPROM from a script using the ST-...

Andrew Watson · 2018-03-22

Posted on March 22, 2018 at 11:37I ended up fixing the problem : during the long loop of writing to the EEPROM, we had an interrupt that was performing a write to EEPROM, and locking it after it was done.

Andrew Watson · 2018-03-20

Posted on March 20, 2018 at 12:16And another update:In the code I posted above, I had DATA_EEPROM_Unlock and DATA_EEPROM_Lock surrounding the outer loop.I moved those calls to between the two loops, and the bug no longer appears.As far as I can tell...

Andrew Watson · 2018-03-20

Posted on March 20, 2018 at 12:01Second update:The problem seems to be occurring within a loop where we do something like this: (simplified a little by replacing some constants and structs)// EEPROMTableStart refers to an array in a struct, it start...

Andrew Watson · 2018-03-20

Posted on March 20, 2018 at 09:59Update with more information: I can't replicate the bug with the debugger attached, since the bug appears during programming, but I dumped the contents of the FLASH SFRs to UART in both cases.The difference when the ...

Andrew Watson · 2017-05-12

Posted on May 12, 2017 at 12:13Thanks,It turns out it was the watchdog timer that wasn't properly frozen. I added the following line to my watchdog init function and it seems it has fixed the issue:DBGMCU_APB1PeriphConfig(DBGMCU_IWDG_STOP, ENABLE);

User statistics

User Activity

STM32L1xx can't write to internal EEPROM after being programmed with ST-Link

When debugging, target MCU continues to run after breakpoint is hit

ST-Link Utility slow to write EEPROM in newer versions

Re: STM32L1xx can't write to internal EEPROM after being programmed with ST-Link

Re: STM32L1xx can't write to internal EEPROM after being programmed with ST-Link

Re: STM32L1xx can't write to internal EEPROM after being programmed with ST-Link

Re: STM32L1xx can't write to internal EEPROM after being programmed with ST-Link

Re: When debugging, target MCU continues to run after breakpoint is hit