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

[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’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