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

[PavelSingh]

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.

 

 

 

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:

 

 

 

Bin file snippet of STL project for Nucleo – L476:

 

 

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.

[Imen.D]

Hello @PavelSingh ,

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

[PavelSingh]

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

 

 

Kind regards,
Pavel

 

 

 

[Tesla DeLorean]

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

[PavelSingh]

Hello Tesla,

Please see below snippet for debug DIR

 

 

[THofr]

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.

 

[PavelSingh]

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

[Petr Sladecek]

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

 

[PavelSingh]

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 

[THofr]

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?

 

[Petr Sladecek]

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  

[PavelSingh]

Hello Petr,

 

Thanks for your response.

 

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) 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