STL flash test failing

[heveskar]

I do not know if this is appropriate place to ask but I will try. We are integrating the STM STL library and we cannot get the flash test to be successful.

This, this, this nor this helped. I believe we are generating the checksums correctly, we tried either post-build step as recommended in the user manual or running the script separately in the CMD. We can see that the CRCs are written in the memory the same way they are written in the .elf. StlFlashStatus is being set to STL_FAILED every time.

Our MCU is STM32H723ZG with 1 MB of flash. Therefore in the configuration, ROM start address is set to 0x08000000UL and ROM end address is set to 0x080FFFFFUL. We are trying flow similar to the default examples, either single test or multiple tests. ROM start address is set to 0x08000000U, even when trying to check 1 flash section, StlFlashStatus is set to STL_FAILED.

Unfortunately we do not have Nucleo H743ZI to test the example project, however we tried the 'G4 variant using Nucleo-G474RE and it worked, so I believe that software settings from our side are correct.

Any ideas what could be wrong?

I have one additional question/clarification, does SW CRC differ from HW CRC calculation-wise? In the utilities there is a CRC function that seems to be doing just a XOR of the input data, which is not the same as the CRC peripheral does, no?

 @Petr Sladecek @Amel NASRI 

EDIT: I forgot that we are using the X-CUBE-STL library

[heveskar]

Update, so now it seems that only the first section (1024 B starting at 0x8000000) fails, but other sections work (STL_PASSED). Still have no idea what can be causing this.

[heveskar]

It was caused by the fact that .isr_vector size was not divisible by 8 so that before the next aligned section, there was an empty word that was throwing off the CRC calculation.

[awiernie]

It seems that I have the same problem. How did you solve the problem that the .isr_vector size was not divisible by 8? 

[heveskar]

Sorry I did not mention the full solution in the original comment. I fixed it in the linker by changing the alignment to 8:

 .isr_vector :
 {
 . = ALIGN(8);
 KEEP(*(.isr_vector)) /* Startup code */
 . = ALIGN(8);
 } >FLASH

 

[awiernie]

We had already tried this and it worked for the first blocks of flash. But later it fails again. We had set all align to 8.

I wonder why one should change align to 8.

The self-test library user guide says only that the binary has to be aligned to 4 bytes.

If the problem comes from uninitialised fill bytes in the gaps between alignment, setting it to 8 bytes would make it even worse as more fill bytes are introduced. 

Do you know why the alignment has to be 8?

[heveskar]

I thought that alignment helps because fill bytes now become part of the section and it no longer throws the CRC calculation off. Why it has to be 8 I do not know. Integration tips application note seems to suggest that the calculation tool changes the binary in such a way that problems with the end address alignment are not present, but obviously it doen't work correctly.

I thought that changing <pattern> value for the safety lib command to 0xFF would maybe help, but when I did that the resulting elf was not even valid.

Furthermore, I seem to recall that I had to keep the .init_array and .fini_array sections at alignment 4, else the CRC check did not work (or maybe the whole app did not work, I am not sure now).

[heveskar]

Actually, I looked at this again and I forgotten that I had knew where the original problem was. For me the culprit is, that when there is that 4-byte "gap" between .isr_vector and .text sections (on my device at address 0x80202cc), even though in the .elf this is filled with 0x00000000 (or it seems so from the STM32CubeProgrammer):

When loaded to the device, there is actually uninitialized memory 0xffffffff:

This is why the CRCs do not match as the safety lib command probably uses 0x00000000 for the calculation. It seems to me that .text section is somehow forced to be aligned to 8 bytes, (even though it is not specified in the linker) and that's where this gap is created when .isr_vector section is not long enough. Maybe you have this similar problem between other sections? I forced all the flash sections' start and end address to alignment 8 (except .init_array and .fini_array as I mentioned before) and all is working correctly for me.

 

PS: IDE memory details for clarity: 

and working configuration: 

 

 

 

[awiernie]

Now it works for me. My CPU was not in stl_user_templacte.c and I had written the wrong STL_ROM_END_ADDR.

Therefore the flash test expected the crc table on a different flash address.

It works with both, alignment of 4 and also of 8. With alignment 8 there are additional fill bytes, but in both versions all are zero in .elf file and also in flash memory after upload.

 

The other project first only worked with alignment 8 but after switching back to 4 it works also. Don't know why, maybe there was another

[PavelSingh]

Hello Awiernie,

I have gone through above discussion. I am also experiencing some thing same, please see below.

 

My code is divided into two parts:

Part 1: bootloader

Part 2: main application

When I am debugging main application using Segger, everthing is working fine, flash test is getting passed.

But when I combine both hex files (bootloader hex + main app hex) and flash through Segger, flash test is getting failed but other logics are working.

Any additional guidance would be greatly appreciated.

 

Regards,
Pavel

 

[Petr Sladecek]

Hello,

I confirm the problem comes from code alignment applied by GCC compiler and linker making unexpectedly gaps between the code sections due to different alignment control what results at default filling of these gaps. This default filling is done differently by GCC compiler and STM32CubeProgrammer used to calculate and make content (CRC results) of the Flash CRC descriptor field as a consequence. Different alignment usually happen when STL is combined with another code or FW (e.g. it was observed after implementation of floating point arithmetic). We strongly suggest to inspect the compiled binary file by IDE build analyzer and verify and detect if any discontinuity appears at the code binary. If the binary file is not continuous, STL works (and all CRC check sums match) only if it is downloaded by the STM32CubeProgrammer but not by e.g. STM32CubeIDE debugger applying the GCC ELF output file and so different default filling of the gaps between the not aligned code sections. Solution is to modify the linker scatter file and force unique alignment of all the sections eliminating these gaps. We met cases when even forcing alignment 8 was not enough to protect this issue.

We haven't observe such a problem at IAR or KEIL compilers so far and its occurrence is still under our investigation.

Best regards,

Petr

[Petr Sladecek]

Hello,

I’m just thinking about sense of checking bootloader integrity during the application run (and so challenging its PST) as appli can put itself to safe mode only at case the problem is found there (in fact not necessarily if appli overall code & data is ok). This results at reset of the application and invoking the bootloader again anyway. It gives me better sense to separate bootloader self-check prior appli code is downloaded and let run appli only at case the load is verified successfully (ether by comparison or by other simple principle including overall CRC check sum) by the bootloader. Appli then checks its own integrity regularly only.

Anyway, STL concept recognizes single integrity area exclusively with common CRC descriptor field filled by CRC results of those sections either fully or partially occupied by non-volatile content. The tool fills only CRCs of occupied sections while it is never calculated above those areas not occupied by any code/data information. This is reason why the integrity subset (a compact range to be checked) must be defined at STL user structures with this principle and always well aligned with the binary (tested range can never go out of the binary). User can define more compact subsets within the integrity area, but their CRC descriptor field calculated by the CubeMX tool is common defined always at the end of the overall integrity area (the size of this field is defined by number of the 1KB sections in the range referred by the CLI parameters).

The CRC calculation is based on the same 32-bit polynomial no matter if HW or SW CRC is applied (CLI has no information which one is used by appli). The utility check is applied internally to a fast verification integrity of some internal STL execution data (to prevent any additional load of the HW CRC unit and taking care about its re-configuration). User can re-use these procedures to do the same with appli data structures.

Best regards,,

Petr