is there any way to find somewhere in memory address information about how many bytes I have written to FLASH memory on STM32H55

[Domy_ST]

Hello ST community,

Is there a way to find information about how many bytes I've written to the flash memory of a certain memory area at some memory address (not starting at 0x0800000, but at 0x0802000)?

When I first power up, the byte counter is initialized to 0, and as I write bytes from address 0x0802000, I count the number of bytes, and at that point, I get the information about the number of bytes written.

But my goal is to know how many bytes I've previously written when I power cycle the STM32H7 MCU. Is there an option that counts the number of bytes written to the flash memory and automatically stores that information somewhere in the memory?

If so, which memory and at what address?

Thanks to anyone who can help me.
Regards

[Andrew Neil]

Is there an option that counts the number of bytes written to the flash memory and automatically stores that information somewhere in the memory?

No - you would have to implement that yourself.

To survive a power cycle, you would need to store it in Flash (or some other non-volatile store).

 

Have you looked at X-CUBE-EEPROM ? It doesn’t seem to directly support H7, but you may be able to inspire from it…

 

PS:

As ​@mƎALLEm pointed out that the title says H5 - that is supported by X-CUBE-EEPROM.

[Domy_ST]

hello ​@Andrew Neil,

ok thanks

[mƎALLEm]

Hello,

1- In the title you mentioned “STM32H55” no part number in ST MCU portfolio with this reference.

2- For power cycle you need to store that in either:

• Back-up SRAM or Buck-up registers. In that case you need to add a battery on VBAT pin.
• Or to store the value in non-volatile memory. In that case the internal flash or external EEPROM/FRAM (if you have one already).

[Domy_ST]

hello ​@mƎALLEm,

Yes, you're right, there's a missing digit that I missed while typing. The product code I'm talking about is STM32H755ZI-Q

[Andrew Neil]

hello ​@mƎALLEm,

The product code I'm talking about is STM32H755ZI-Q

That seems to be a Nucleo board?

https://www.st.com/en/evaluation-tools/nucleo-h755zi-q.html

 

So the actual STM32 chip is STM32H755ZI:

https://www.st.com/en/microcontrollers-microprocessors/stm32h755zi.html

 

[Karl Yamashita]

You can reserve a 16bit or 32bit address for number of bytes written. So after you write your bytes, just write the count value to that specific address.

You can even calculate the bytes as a 16bit or 32bit checksum and save it. When you read back your bytes and calculate the checksum, you can verify it against the stored checksum so you know the bytes are valid.

[TDK]

Read them on powerup and count. Reading memory is very fast. Should take milliseconds to find the first erased page.

[db16122]

it seems the request can be part of EEPROM enmulation with MCU internal flash.

Please check the application note for AN4894 How to use EEPROM emulation on STM32 MCUs

You can read the flash content based on address and check the data already written into 

[Andrew Neil]

Please check the application note for AN4894 How to use EEPROM emulation on STM32 MCUs

Yes, that’s the  X-CUBE-EEPROM which I mentioned earlier.

 

[Domy_ST]

Hi everyone,

sorry for writing now, but I haven't received any notifications about your messages. I just noticed this now that I'm back on this post.

I tried saving the checksum and byte count data in the 64-bit flash memory, dedicated to two FLASH memory addresses. The problem is that when I need to update the software, everything stored in the FLASH memory is automatically erased, including the two addresses with saved data. FLASH is the only memory that never gets erased during a power cycle.

RAM D1, D2, and D3 are erased every power cycle, and that doesn't work for me. Regarding RAM backup with VBat, I can't do it because my project doesn't include a battery to power it.

Are there any memory addresses that are never erased during a power cycle? Aside from the external memory (EEPROM), I can't use that either.

[Andrew Neil]

The problem is that when I need to update the software, everything stored in the FLASH memory is automatically erased,

I can’t see where you’ve said what tools you’re using ?

CubeIDE will only erase as much Flash as necessary for the code; other IDEs should have options to do the same.

 

PS:

RAM D1, D2, and D3 are erased every power cycle

They are not actually erased.

It is the nature of RAM that it is volatile - ie, it cannot retain data unless there is power present.

So, after a power-cycle, RAM will inherently lose its contents.

 

However, there is also the C initialisation code, which runs after every reset - whether power is lost or not.

You can avoid this by defining sections to not be initialised.

Again, this will depend on your toolchain - but for GCC:

 

[Domy_ST]

hello ​@Andrew Neil ,

Since the STM32H755's flash memory is 1024 KB in total, the SW + data for CRC32 and byte counting is only in 128 KB, as in the following linker:

/* Memories definition */
MEMORY
{
  RAM_D1 (xrw)   : ORIGIN = 0x24000000, LENGTH =  512K
  FLASH   (rx)   : ORIGIN = 0x08000000, LENGTH = 128K    
  DTCMRAM (xrw)  : ORIGIN = 0x20000000, LENGTH = 128K
  RAM_D2 (xrw)   : ORIGIN = 0x30000000, LENGTH = 288K
  RAM_D3 (xrw)   : ORIGIN = 0x38000000, LENGTH = 64K
  ITCMRAM (xrw)  : ORIGIN = 0x00000000, LENGTH = 64K
}

while the remaining 896 KB is dedicated to other SW.

I could reduce the 128 KB to 127 KB to dedicate only to SW (erase + programming), while the remaining 1 KB can be dedicated to permanent data for the checksum and byte counting, and future data that I would like to store.

But the point is that with this architecture, the STM32H755 allows for minimal programming with 128 KB blocks.

 

regarding the RAM, I also changed that in the linker to use no-init only for 4K of RAM but after several power cycle attempts the data is still lost

[LCE]

I think the probably worst feature of the H7s is that the smallest flash erase is sector erase, which means 128 kB minimum.

This makes it mostly unusable for standard EEPROM-like use, like saving some user data every now and then.

The 2nd worst is probably that they have only 1 flash bank (at least the H723 .. H735 that I used), which means there’s no “read while write”, so while erasing or writing it can only work from RAM.

 

Considering all that, I think ​@TDK ‘s idea (counting bytes until finding empty space) is actually the best.

If that is doing what you need, but I haven’t really understood what your goal is.

[Andrew Neil]

The 2nd worst is probably that they have only 1 flash bank (at least the H723 .. H735 that I used), 

It seems that ​@Domy_ST is using STM32H755ZI ?

That one does have dual banks:

https://www.st.com/resource/en/datasheet/stm32h755zi.pdf#page=20

[Domy_ST]

hi ​@LCE ​@Andrew Neil,

Yes, I could follow ​@TDK  suggestion of reading the bytes and counting them until I find a blank. This means counting the bytes until I find the value 0xFFFFFFFF. This doesn't mean I'll never write the value 0xFFFFFFFF; I could have written it myself and still have to count the number of bytes.

Regarding the memory space I need without ever being erased, even during a power cycle, I would need to enter the checksum value (CRC32) and the number of bytes programmed into the flash. This would be used to compare the byte count I mentioned earlier after reading all the data from the flash up to that byte size (the byte count I mentioned earlier) at the first power-up.

Regarding the STM32H755 product that I have for testing and to continue development, I know it has two memory banks: one dedicated to the CM7 core and one for the CM4 core. but in my project I have to consider only one memory bank because the project will be used only on STM32H725 product which has only one core and therefore only one memory bank.

[LCE]

> … because the project will be used only on STM32H725 product …

That’s … wild. Better get some board with the targeted H725.

And again, considering the minimum 128 kB erase size, better spend some extra ~0.5 $/€ and ~20mm² board space and use an external non-volatile memory.

[Domy_ST]

hi ​@LCE,

I agree with you because on the product STM32H725 only we developers fully understand the problem that arises... but unfortunately it's not my decision that will be made on that product but on those who don't know the problem, so non-developers.

[TDK]

The scheme is too fragile anyway. There is a nonzero delay between updating flash and updating this non-existent memory to hold the data in flash. The two will be out of sync if power goes away when writing.

Lots of ways to solve this problem. external eeprom chip, emulation, counting bytes. Take your pick among the possibilities.