We have STM32L011 and L031 what shows Eeprom @ 0x0808 0000. Normally Eeprom write is locked. Application writes well before power shutdown is expected. Ozone shows hexdump with View-Memory Window (Alt+Shft+M) with correct Eeprom contents. If I modify the contents in hex window, I can write to byte/word/dword inside the hexdump. Written location turns red and shows new value. Same time other locations turn red and it seems big area outside the modified location is destroyed.
As we can see in the Ozone console output, the memory write is done using a page size of 512 Bytes while Datasheet shows Eeprom simulated by Flash with a page size of only 4 Bytes. This fact seems not respected by Jlink.
After described write attempt it comes even worster. The content of the Ozone Eeprom memory window is not identical with the physical content until exit and restart Ozone. Reload and restart application is insufficient. My startup function copies Eeprom to Ram. If executing in realtime until breakpoint, the Ram contents are identical to the Eeprom contents after startup copy. If executing in single step, its doing something else. The Ram contains now the wrong data identical to what is displayed in Ozones Eeprom data window.
As we can see in the Ozone console output, the memory write is done using a page size of 512 Bytes while Datasheet shows Eeprom simulated by Flash with a page size of only 4 Bytes. This fact seems not respected by Jlink.
After described write attempt it comes even worster. The content of the Ozone Eeprom memory window is not identical with the physical content until exit and restart Ozone. Reload and restart application is insufficient. My startup function copies Eeprom to Ram. If executing in realtime until breakpoint, the Ram contents are identical to the Eeprom contents after startup copy. If executing in single step, its doing something else. The Ram contains now the wrong data identical to what is displayed in Ozones Eeprom data window.