STM32H7 HAL Flash Program

[Gasper Korinsek]

Posted on June 29, 2017 at 14:22

7There is a potential bug in the HAL library ver 1.0 for the STM32H7:

Functions FLASH_Erase_Sector and FLASH_MassErase (file stm32h7xx_hal_flash_ex.c,) change the PSIZE value in the FLASH->CRx register according to the VoltageRange argument. The function HAL_FLASH_Program (stm32h7xx_hal_flash.c) seems to expect the default PSIZE value (64-bit).

In other words: calling FLASH_Erase_Sector or FLASH_MassErase functions with a VoltageRange argument other than FLASH_VOLTAGE_RANGE_4, changes the behaviour of the HAL_FLASH_Program function.

Separate questions:

Is there any plan to support 8, 16 or 32-bit programming parallelisms in the HAL_FLASH_Program API?

#flash #hal #stm32h7

[Imen.D]

Posted on June 29, 2017 at 15:17

Hello

tenson

,

I will check and raiseinternally yourreported issue and therequest to

support 8, 16 or 32-bit programming parallelisms in the HAL_FLASH_Program API

.

Icome back to you if we will have any taken actions.

Regards

Imen

[Gasper Korinsek]

Posted on June 29, 2017 at 15:20

Hello Imen D.

Thank you for fast response.

[Gasper Korinsek]

Posted on June 29, 2017 at 17:18

One further question regarding STM32H7xx FLASH operations:

Looking at the RM0433 user manual:

Chapter 3.2, page 112

Flash programming by 256 bits

Double-word, word, half-word and byte write operations

Chapter 3.3.7, page 121

Since a 10-bit ECC code is associated to each 256-bit data Flash word, only write

operations by 256 bits are supported.

Does this mean that it is not possible to write a single byte into the FLASH memory on the STM32H7?

Thank you and best regards,

[Imen.D]

Posted on June 29, 2017 at 18:45

Hi

Korinsek.Gasper

,

Does this mean that it is not possible to write a single byte into the FLASH memory on the STM32H7?

It is possible to force

the write operation without filling the missing data by activating the FW1/2

bit in FLASH_CR1/2.

This will force all missing data “high�?.

You can use the SRAM

backup to build a word with 256 bit before write into the Flash. It's more optimized.

Regards

Imen

[Gasper Korinsek]

Posted on June 30, 2017 at 08:39

Hi Imen

Thank you for explanation and fast response. I agree that writing a byte is possible, but not in a manner as in an example below. I'm very sorry to keep nagging with this topic, but we're migrating a project from the STM32F2 where such an operation was possible (we've used the described method to 'update' a checksum in the beginning of a FLASH sector after all data was successfully written).

Example:

First write at flash address 0x08020000:

FF FF FF FF 01 23 45 67

01 23 45 67 89 AB CE EF

01 23 45 67 89 AB CE EF

01 23 45 67 89 AB CE EF

Subsequent writes to other addresses.

Last write at flash address 0x08020000:

AB AB AB AB 01 23 45 67

01 23 45 67 89 AB CE EF

01 23 45 67 89 AB CE EF

01 23 45 67 89 AB CE EF

The main reason why I don't see how the example above could be possible -> RM0433 user manual, page121:

It is not recommended to overwrite a not virgin Flash word. The result may result in an

inconsistent ECC code. The Flash interface can report systematically ECC errors. A validscenario that can be supported is to overwrite with all zero data. In this case thecorresponding ECC code will also be all zero. Consequently, no ECC errors will be detectedduring the read.

Thank you and best regards,

[Volker Bremauer]

Posted on December 06, 2017 at 17:08

Hello Imen,

I am in the same situaltion than Gasper before.

In my application I want to program a new firmware by loading an S-Record file.Normally each line ouf the S-Record have a maximum usable byte length of 32 bytes.

Also each S-record line have a starting address in 32 byte blocks.

e.g.

S32508040B003846FFF71FFCE9E73546E7E751F8040C0028A0F10400BCBF0B58C0187047000098

S32508040B20044A05491368002B08BF0B461844106018467047F0400020E8BE0020F8B500BFE6S31908040B40F8BC08BC9E467047F8B500BFF8BC08BC9E467047FDhere the address 08040B00,08040B20,08040B40. To programm such a one is not a problem, because it fits to the spec of the H743 flash.

Depending on the linker file definition, sometimes I get a different staring address e.g.

S32508040B58010002000400060008000A000C0010002000400080000001010002000400060042

S32508040B7808000A000C001000200040008000000100061016000610160100020004000600D7

here the address 08040B58,08040B58. This address is in between the 32 bit range and overlapps to 32 byte/256 bit sections.

To simulate this matter made a small application trying to understand the behavior of the H743.

* open an buffer of 32 bytes

* copy the content of the one 32 byte Block from flash into Ram.

* overwrite the RAM content with  the new const data.

* flash the complete 32 byte block to the flash.

Here the test result:

1. erasing the flash sector

1. Writing first Block of data

                        //   1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2

const    char Teststr3[] = ''00112233445566778899AABBCCDDEEFFC0C1C2C3C4C5C6C7C8C9CACBCCCDCECF'';const   uint32_t address3 = 0x08020B38;const   uint32_t length3 = 0x25-5; // 32

      All seems to be ok.

2. Writing the second Block of data

                       //   1 2

const    char Teststrx[] = ''AABB'';const   uint32_t addressx = 0x08020B20;const   uint32_t lengthx = 0x2; // 2

      This also looks perfect.

3. Writing next Block of data  

                        //   1 2 3

const    char Teststry[] = ''CCDDEE'';const   uint32_t addressy = 0x08020B2A;const   uint32_t lengthy = 0x3; // 3

What happend ?

Memory 0x8020B1 changed from BB --> 3B

4. Writing next Block of data  

                        //   1 2 3

const    char Teststri[] = ''ABCDEF'';const   uint32_t addressi = 0x08020B59;const   uint32_t lengthi = 0x3; // 3Now something happend again.

The reading of the flash 256bit-section cannot be performed by the debugger

.

Restart debugger or/and ON/OFF power not helps.

Only a new erasing of the flash solve this problem (see 1.).Now my question, can you or somebody else explain what happen at 3.) and 4.) ?If the eclipse project is needed, I can provide it.

Thanks in advance.

BR Volker

[Tesla DeLorean]

Posted on December 06, 2017 at 17:43

Most likely due to ECC and faulting. ie trying to fix vs detect multiple bit errors

The flash lines are 256 + ECC bits in length, when you start cherry picking what you write and rewrite into the line you're likely to break things.

When processing sparse or unaligned hex files you really need to cache the data in larger blocks, and flush the data as aligned lines into the Flash array, and finally once you've encountered the terminal record. Either your S-Record processing needs to get smarter and handle multiple lines so it can fold into single aligned writes, or you work with packaged binary data, and use something like X-Modem with larger and aligned blocks.

[andre239955_st]

Posted on April 16, 2018 at 09:04

Hi, I am using V1.2.0 of stm32h7xx_hal_flash_ex to erase individual sectors. Directly after the erase cycle I do a blank check which reports errors. When setting a breakpoint I can see in the debugger that effectively the flash is not empty:

When stepping the flash contents updates and then it is completely erased.

I have tried with different voltage range settings but nothing helps. What could be the issue here?

Thanks,

Andre

[tarek tayachi_O]

Posted on May 04, 2018 at 11:52

Hello Andre,

1/ Does the HAL API HAL_FLASHEx_Erase() report a HAL_ERROR or HAL_OK?

2/ Is Cache activated in your application?

In fact, when cache is activated, the CPU could be seeing an old data available in cache, and not the new data available in flash memory. So, a cache maintenance in needed after erase.

BR,

Tarek