Skip to main content
CRoes.13
CRoes.13
Associate
July 12, 2019
Question

STM32L496 error while writing flash after programming flash page with JLink

  • July 12, 2019
  • 3 replies
  • 1174 views

Hi,

For our application we want to write a region in flash with configuration files during production. This is handled by the Segger JLink that writes the program bin and the configuration bin in two parts of the memory.

While the firmware can read out the values, it is not able to remove the values or write something on the address after the pre-programmed values.

However, if we only program the firmware and let this handle all sorts of configuration writing/removing there is no problem. Comparing the flash areas of these two situations shows no differences.

Single step debugging and reading out the flash registers shows that the SR register gives a value of 0xA8 after writing the first double word.

We use the NVStore from mbed os 5.12 to handle the memory management.

If more information is required, I am happy to add this to the question.

This topic has been closed for replies.

3 replies

Bob S
Bob S
Super User
July 12, 2019

I know nothing about NVStore and how it works, but the FLASH SR value shows the PROGERR set, which means something tried to write to a FLASH location that wasn't erased (i.e. not 0xffffffffffffffff). It also shows the PGSERR and PGAERR bits, which you can look up yourself.

One possibility might be that the config data written via the JLink is not correctly parsed during the NVStore initialization code, so that it tries writing to a location that it shouldn't. Or maybe the data programmed via JLink has extra bytes at the end???? Try single-stepping through the write operation, see what address NVStore decides to try and write to, then check to see if that location is (1) aligned to an 8-byte boundary, and (2) contains 8 bytes of 0xff. You might also check that all of the FLASH error flags in the SR get cleared before attempting the write operation.

CRoes.13
CRoes.13Author
Associate
July 16, 2019

Just did an extra check.

The page I want to write to is on 0x807f000. Due to the prestored config data it will start writing new 24 bytes of new data on 0x807f0A0.

This happens with a double word at a time.

After writing the first uint32_t of the double word the PROGERR flag gets raised. However, doing a memread on this location with the JLINK tools show only 0xFFFFFFF on that location (and on the rest of the page). After writing the 2nd byte the PGSERR and PGAERR get raised.

Writing the flash is done using the HAL_FLASH_Program function in the stm32l4xx_hal_flash files.

Do I miss something here?

Bob S
Bob S
Super User
July 16, 2019

Hmmmm.... Since it appears that you are single-stepping through the HAL_FLASH_Program() function, make sure the address is really what you think it is when you get down into FLASH_Program_DoubleWord (presuming you are using FLASH_TYPEPROGRAM_DOUBLEWORD).

You might also add code to read the FLASH contents before you call HAL_FLASH_Program() and have your program verify all 8 bytes are 0xff, just in case there is something funky with what the J-Link is showing. Does the JLink and/or your IDE cache FLASH data under the presumption that it shouldn't be changing????? Do you have any memory protection (PCROP/RDP/WRP) enabled?

Terms & ConditionsAccessibility statement