cancel
Showing results for 
Search instead for 
Did you mean: 

STL v4.0.0. : Flash test not passed + bin file size is 393MB

PavelSingh
Associate II

We have tested the STL package in 2 scenarios for Flash test on STM32L452:

 

CASE 1:

 

Linker settings:

FLASH    (rx)    : ORIGIN = 0x8000000,   LENGTH = 512K

 

Pre-Post build settings:

0x08000000 0x08080000 0x400

 

STL user template settings:

/* FLASH configuration */

#define STL_ROM_START_ADDR (0x08000000UL) /* customizable */

#define STL_ROM_END_ADDR   (0x0807FFFFUL)

 

Flash test passed.

 

 

CASE 2: (our usage scenario)

 

Linker settings:

FLASH    (rx)    : ORIGIN = 0x800E000,   LENGTH = 456K

 

Pre-Post build settings:

0x0800E000 0x08080000 0x400

 

STL user template settings:

/* FLASH configuration */

#define STL_ROM_START_ADDR (0x0800E000UL) /* customizable */

#define STL_ROM_END_ADDR   (0x0807FFFFUL)

 

Unable to start test please see below snippet.

PavelSingh_0-1738151898563.png

 

 

 

Code is divided into 2 regions, bootloader application and production application.

56KB is ket aside for bootloader, reason for FLASH ORIGIN = 0x800E000.

 

 

Thers is one more problem I want to discuss, please see below snippet:

 

PavelSingh_1-1738151898564.png

 

 

Bin file snippet of STL project for Nucleo – L476:

PavelSingh_2-1738151898564.png

 

 

Bin file size is 393MB, this is huge, we can’t bootload this file using Bootloader App. It should be in KBs.

 

I would appreciate if you can suggest us how we could resolve both the above problems.

 

Please let me know if you need more information.

11 REPLIES 11
Petr Sladecek
ST Employee

Hello,

pls verify if CRC area is properly programmed at the device and if each code 1KB section applied for the test has its CRC pattern computed and stored with adequate offset at the CRC area. Verify if binary under test is truly compact and if there are no undefined bytes between code sections due to their wrong alignment. It could be debuggers fill these gaps by different default patterns what could lead to the different CRC results. Of course the binary start and end must be aligned as required by the UM.

Best regards,

Petr  

Hello Petr,

 

Thanks for your response.

 

My code is divided into two parts:

Part 1: bootloader

PavelSingh_0-1740199099731.png

 

Part 2: main application

PavelSingh_1-1740199099432.png

 

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) using srec utility and flash through Segger, flash test is getting failed but other logics are working.

Any additional guidance would be greatly appreciated.

 

Regards,
Pavel