Running into a strange problem . We're working on a safety project and using the ST-provided STL library on an STM32H743. Failing the Flash test when attempting to get 100% test coverage. Mode details in section below.

DamienF · ‎2021-06-30

The STL library is configured to test a multiple of sectors at a time (128kByte each).

Our usage model is closely derived from the Nucleo reference project that ST provides as an aid to integrate the STL library; and we're using the IAR project in that package.

As of today our code utilizes 3 sectors (2 complete and one partial).

The Flash test (via STL_SCH_RunFlashTM API) works well on the first 2 sectors, but always fails the 3rd.

Turns out, this is because the ST-provided CRC table generator utility (STM32_Programmer_CLI.exe called with option -sl) does not generate CRCs past the last byte of in-use memory inside the 3rd sector.

As an attempt to remedy the problem I'm using the memory fill option built into the IAR IDE, to force a fill to a known pattern, different from 0xFF.

This results in the IAR IDE throwing a "Multiple images overlap" error when I attempt to load the debug build into target.

The attached file "ELF-map.txt" shows exact error message and the output of an ELF viewer.

One can clearly see the overlap in the third log, bottom of the file. It appears that the CRC table generator utility did some padding for 32-bit alignment on each program section, possibly encroaching on the next.

What is you recommendation?

Joining the 2 segments A0 and Fill1 prior to calling the CRC table generator utility?

Other?

Note: the issue is only with the ELF file that gets loaded in the target by the IDE. I can achieve 100% coverage (all 3 sectors) if I download the debug *.bin file outside of the IDE via the STM32CubeProgrammer. I'm taking about the *.bin file that gets generated by the IDE alongside the ELF file.

Amel NASRI · ‎2021-07-01

Hello @DamienF ,

I got the confirmation that this is a known issue when the code is not aligned to 32-bit word. This is a basic block hardcoded by STL. If you refer to the firmware user manual that you should have received with STL, the precondition of the CRC calculation is described in the chapter "Flash memory tests" especially where it is written that "the boundaries of the user program must be 32-bit aligned".

The root cause of the overlaps between images is that the STM32CubeProgrammer uses automatic padding by zeros when the code is not word aligned while it ignores other segments of the ELF file provided by compiler keeping information about automatic filling of the memory gaps by a predefined pattern.

The solution to avoid such problem is to assure 32-bit alignment of the code prior calling the ST CRC calculation tool to avoid automatic padding done by STM32CubeProgrammer.

-Amel

PS: Once your question is answered, please click on "Select as Best" for the comment containing the answer to your initial question.

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

View solution in original post

Amel NASRI · ‎2021-07-01

Hello @DamienF ,

I'll share your request with our STL expert and I'll keep you informed on this regard.

-Amel

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Amel NASRI · ‎2021-07-01

Internal ticket number: 109974

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Amel NASRI · ‎2021-07-01

Hello @DamienF ,

I got the confirmation that this is a known issue when the code is not aligned to 32-bit word. This is a basic block hardcoded by STL. If you refer to the firmware user manual that you should have received with STL, the precondition of the CRC calculation is described in the chapter "Flash memory tests" especially where it is written that "the boundaries of the user program must be 32-bit aligned".

The root cause of the overlaps between images is that the STM32CubeProgrammer uses automatic padding by zeros when the code is not word aligned while it ignores other segments of the ELF file provided by compiler keeping information about automatic filling of the memory gaps by a predefined pattern.

The solution to avoid such problem is to assure 32-bit alignment of the code prior calling the ST CRC calculation tool to avoid automatic padding done by STM32CubeProgrammer.

-Amel

PS: Once your question is answered, please click on "Select as Best" for the comment containing the answer to your initial question.

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

DamienF · ‎2021-07-06

Merci Amel. I ended up modifying the linker file to force 32-bit alignment and that resolved the issue.

Best-

Damien.

Amel NASRI · ‎2021-07-07

Glad to know that my contribution was helpful for you, @DamienF .

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Heikon · ‎2022-09-13

Hey you guys,

got the same problem this week and found this chat to solve it.

I use the STM32F302VC and am just implementing the STL lib.

Is there any new STM32_Programmer_CLI to solve the problem by the CRC calculator and merger?

@DamienF how do you modify the linker file to resolve it?

You´ll find my linker file attached.

Hope anyone can help me in this issue, thanks in advance

Heko

DamienF · ‎2022-09-13

First off your ICF file appears to be way off to me; I'd recommend you use as a baseline the ICF file provided with the STM32CubeExpansion STL package you must have received under NDA. Also I believe talking with your assigned FAE at ST is your best option moving forward since this is NDA stuff.

Heikon · ‎2022-09-13

Hey Damian, thanks for your fast reply. Yesterday at night I found out that the option "use flash loader(s)" in the debugger setting was set. When deactivating this it works. The flash loader must have caused the alignment problem.

By the way.... what is NDA??

NVerm.2 · ‎2024-02-06

Hi @Amel NASRI

I recently added a function HAL_FLASH_Program() to implement bootloader whereas I am using STL for safety in STM32G0, I found STL_SCH_RunFlashTM() starts failing, although I don't call HAL_FLASH_Program(), Just wanted to understand what could be the reason? Is there something I am missing?

Any help would be appreciated.

Thank you,
Neeraj