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.

9 REPLIES 9
Imen.D
ST Employee

Hello @PavelSingh ,

Maybe you have the same issue as described in this post: Solved: STL flash test failing - STMicroelectronics Community

When your question is answered, please close this topic by clicking "Accept as Solution".
Thanks
Imen

The commas also look very oddly placed. Show a DIR from a DOS Box or File Manager

Large .BIN files typically occur due to large discontinuous sections in a .ELF file, or .HEX

BIN files can't have VOIDS in them, and must describe all space between the beginning and ending addresses.

Inspect the .ELF with tools like OBJCOPY, OBJDUMP, FROMELF, etc, you're likely outputting data into RAM spaces or EXTERNAL MEMORY, which wouldn't be appropriate to be in the .BIN

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

Hello Tesla,

Please see below snippet for debug DIR

PavelSingh_0-1738220021112.png

 

 

Hello Imen,

I had seen that post earlier. There FLASH ORIGIN is 0x8000000 but in our case FLASH  ORIGIN is 0x800E000, as initial 56KB is kept aside for bootloader.

And we are getting below warning after build

PavelSingh_3-1738220822503.png

 

 

Kind regards,
Pavel

 

 

 

THofr
Associate II

I had a similar problem with the STM32F746.

My memory structure:

0x0800 0000: Bootloader
0x0800 8000: Reserved
0x0801 0000: Data / Parameter
0x0802 0000: Firmware
0x0808 0000: Reserved

The checksum should only calculated over the firmware.

 

The CRC-Test (STL_SCH_RunFlashTM()) now works with the following adjustments:

stl_user_param_template. c:
#define STL_ROM_START_ADDR (0x08020000UL)
#define STL_ROM_END_ADDR (0x0807FFFFUL)

 

This defines results in a CRC area size of 0x600 (Flashsize / SliceSize * 4)
The CRC area starts at 0x0807FA00 (STL_ROM_END_ADDR - CRC area size + 1)

This results in the following memory structure:
0x0800 0000: Bootloader
0x0800 8000: Reseviert
0x0801 0000: Data / Parameter
0x0802 0000: Firmware
0x0807 FA00: CRC-Area
0x0808 0000: Reserved

Now I adjust the CRC-Test addresses in the Firmware and compile the project:
#define TEST_ROM_START_ADDR 0x08020000UL
#define TEST_ROM_END_ADDR (0x0807FA00UL - 1)


I fill the generated firmware HEX file up to 0x0807FA00 with 0xFF:
srec_cat. exe FW.hex -Intel --fill 0xFF 0x08020000 0x0807FA00 -out FW.hex -Intel

Then I create the CRC area:
STM32_Programmer_CLI.exe -sl FW.hex 0x08020000 0x08080000 0x400

 

Maybe there is an easier way. But this one works for me.

 

Petr Sladecek
ST Employee

Hello Pavel,

I confirm, the STM32CubeProgrammer CLI (applied at the post build command) calculates CRC check sums for those flash segments occupied by code exclusively. The warning message signalizes that no code was detected at the range specified for the CRC calculations so the programmer has found nothing to modify.

Best regards,

Petr

 

Hello Thofr,

Thanks for your response.

I have done the following changes:

Linker settings:

FLASH    (rx)    : ORIGIN = 0x8010000,   LENGTH = 448K

 

Pre-Post build settings:

0x08010000 0x08080000 0x400

 

STL user template settings:

/* FLASH configuration */

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

#define STL_ROM_END_ADDR   (0x0807FFFFUL)

 

Flash test passed.

 

But bin file size is still coming 393MB, so I can't able to bootload bin file.

And also hex file is not working when flashing through Jlink.

Code is only working in debug mode and run mode using Jlink.

 

Kind regards,

Pavel

PavelSingh
Associate II

Hello All,

 

Flash test is passing while I am in debug mode or run mode.

But failing when flashing hex file in mcu using Segger J-Flash lite.

 

Kind regards,

Pavel 

Hi Pavel,

check if the CRC-Area starts at 0x0807F999, both in the Hex-File and in the debugger.

STM32_Programmer_CLI.exe inject the CRC-Area in the Hex-File. So you have to programm the Ouput-File from STM32_Programmer_CLI.exe.

Maybe that's the problem?