Partial or Full chip erase before programming?

[Andrew Neil]

Keil (among others) allows the choice of whether to do a full or partial erase before programming:

Is it possible to do that in STM32CubeIDE ?

If so, how ?

[BarryWhit]

If your requirements are to specifically do this through existing options provided by the IDE - I can't help.

But CubeProgrammerCLT does give you fine control about what to erase and what to write:

CMD> STM32_Programmer_CLI.exe
Available commands for STM32 MCU:

 -e,     --erase        : Erase memory pages/sectors devices: 
                          Not supported for STM32MP
     [all]              : Erase all sectors
     [<sectorsCodes>]   : Erase the specified sectors identified by sectors
                          codes. ex: 0, 1, 2 to erase sectors 0, 1 and 2
                          for EEPROM : ed1 & ed2  
     [<[start end]>]    : Erase the specified sectors starting from
                          start code to end code, ex: -e [5 10]
 -w,     --write            
 -d,     --download     : Download the content of a file into device memory
     <file_path>        : File path name to be downloaded: (bin, hex, srec, s19
                          elf, stm32 or tsv file)
     [<address>]        : Start address of download
 -w64                   : Write a 64-bits data into device memory
     <address>          : Start address of download
     <64-bit_data>      : 64-bit data to be downloaded
                          values should not be separated by space
 -w32                   : Write a 32-bits data into device memory
     <address>          : Start address of download
     <32-bit_data>      : 32-bit data to be downloaded
                          values should be separated by space

So with some tinkering, you could probably get what you want by that route.

Alternatively, the open-source flashrom project supports stlinkv3, so you could also hack a custom command into that.

Once you have a script/program that does what you want, you should be able to plug that into your IDE flow so that programming is done using that tool. Worst case, jerryrig a file-watcher util to launch your download script whenever it detects a change in the compiled binary, and tell your IDE not to download when you start a debug session.

[MM..1]

Then somethink in your code place some on end of flash = linker erase all flash.

Show log from GDB flashing code . Or maybe you dont use ST GDB for load, how it does JLink and other probes maybe differ

[Andrew Neil]

---

@MM..1 wrote:

Show log from GDB flashing code .

---

Is that log saved somewhere?

[BarryWhit]

---

@Andrew Neil wrote: Using Flash for non-volatile data storage (EEPROM emulation) - where you want to be able to down load new firmware without erasing the NV data.

---

---

Have you tried modifying the linker script to exclude a portion of flash address space, and allocating that range to a new custom section dedicated to NV storage?

[Andrew Neil]

So far, I've just used it as-is from the App Note - which doesn't modify the linker script; just uses "magic number" addresses for NV storage:

#define NB_OF_PAGES 2

/* Pages 0 and 1 base and end addresses */
#define PAGE0_BASE_ADDRESS    ((uint32_t)(EEPROM_START_ADDRESS + 0x0000))
#define PAGE0_END_ADDRESS     ((uint32_t)(EEPROM_START_ADDRESS + (PAGE_SIZE - 1)))

#define PAGE1_BASE_ADDRESS    ((uint32_t)(EEPROM_START_ADDRESS + 0x0400))
#define PAGE1_END_ADDRESS     ((uint32_t)(EEPROM_START_ADDRESS + (2 * PAGE_SIZE - 1)))

uint16_t EE_Init(void)
{
  uint16_t PageStatus0 = 6, PageStatus1 = 6;
  uint16_t EepromStatus = 0;
  uint16_t FlashStatus;

  /* Get Page0 status */
  PageStatus0 = (*(__IO uint16_t*)PAGE0_BASE_ADDRESS);
  /* Get Page1 status */
  PageStatus1 = (*(__IO uint16_t*)PAGE1_BASE_ADDRESS);

So the tools would have no knowledge that the space was being used for anything?

(this does strike me as a Bad Idea, but I hadn't got as far as addressing that yet)

Perhaps @Semer CHERNI (or someone else from ST) could confirm what should be the behaviour of STM32CubeIDE here - should it be erasing the whole chip, or should just erase enough to cover the code being loaded?

Off for the weekend now ...

[Pavel A.]

> So the tools would have no knowledge that the space was being used for anything?

At least the GNU tools have no idea. IAR toolchain seems to be smarter in interop between compiler and linker. (But I don't use it recently, as the customers migrate to "free cheese").