[Error] Building a custom external loader for a custom board based on a STM32F7 MCU

[boomerblur]

Posted on March 15, 2018 at 04:20

Hi !!!

I am new member of STM32 MCU. I'm working 

 on a custom board based on a STM32F7 MCU for a GUI projects. In my projects, I store a lot of data for GUI such as: Imgae data, Fonts, Audio data in QSPI Flash. My MCU is STM32F769NI and my QSP Flash is MX25L512, that is same of STM32F769I - Discovery. When I use STM32CubeProgramer  to program the demo file supply by CubeMX Driver to my board then every thing is OK. But When I build my external loader then change file

extension

  from *.out to *.stldr (I am using IAR ) this error is appear. My external loader is follow example in ''C:\Program Files\STMicroelectronics\STM32Cube\STM32CubeProgrammer\bin\ExternalLoader\N25Q256A_STM32L476G-EVAL_Cube''. In my program I use BSP funtion supply by CUBE MX, and I check funtion by funtion same work. I'm stuck in this problem

.  Where is my error.  I attack my project in this post.  Can every one help me ? Thank you !!!

#stm32cubeprogramer #external-flash-loader #stm32f7

[Buelent Cakir]

Posted on March 15, 2018 at 04:45

Your ICF File doesn't look ok. You need to consider that the external loader will be moved to the ram and executed from there.

I use this in the ICF:

define symbol __ICFEDIT_region_RAM_start__   = 0x20000004;

define symbol __ICFEDIT_region_RAM_end__     = 0x21000000;

define memory mem with size = 4G;

define region RAM_region   = mem:[from __ICFEDIT_region_RAM_start__   to __ICFEDIT_region_RAM_end__];

define block RAM_BLOCK with fixed order {readonly code, readonly data, readwrite };

define block Info_BLOCK with fixed order { readonly data object Dev_Inf.o};

place at start of RAM_region    { block RAM_BLOCK };

place in RAM_region   { block Info_BLOCK };

do not initialize  { section .info, readwrite };

[boomerblur]

Posted on March 15, 2018 at 05:34

Hi Thanks for your quickly reply. In properties of project I select tab Linker - > I chose override default linker to select my External-Flash-Linker.icf file then I copy all your comment code of linker at this file. But after build project I see in the map file ''P2'':  place in [from 0x00000000 to 0x00000400] { block Info_BLOCK } is not correct. What is wrong ?.

[Tesla DeLorean]

Posted on March 16, 2018 at 17:49

Not using IAR, created project and rebuilt in Keil

________________

Attachments :

MX25L512-STM32F769-CUSTOMBOARD.stldr.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Hxsv&d=%2Fa%2F0X0000000b1n%2FKzdZm_88L0F2CqOYMVgFqUzCJR6Gf.EELTr9bFDZ2fc&asPdf=false

[Tesla DeLorean]

Posted on March 17, 2018 at 00:09

Not sure that has enough code in it to initialize the pins

Would need to know the pins in use, the external crystal speed, if present, and perhaps available USART or LEDs for debugging.

In the mean time I DID recreate the N25Q128A loader for the STM32F746G-DISCO using HAL, ST doesn't provide the example source for that because they use an SPL based library they tell everyone doesn't exist. I did some initial testing on my version and it did seem to function, but would take input from others. The Keil template from ST also didn't seem to work on uV5.23

________________

Attachments :

N25Q128A_STM32F746G_DISCO_TEST001.stldr.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HxqC&d=%2Fa%2F0X0000000b1o%2Fce3lm.ema1jWLRZNEOI.vs1nLR7oQ3EVvrOedLK3yFU&asPdf=false

[Buelent Cakir]

Posted on March 17, 2018 at 00:35

Tested with St-Link 4.0

Error at programing:

00:32:38 : The elf loader Sector Erase function fails.

00:32:38 : Memory-Loader error

Error at Sector Erase:

00:34:06 : External memory sector 0x90000000 is not erased. Verify the memory protection.

00:34:06 : External memory sector 0x90010000 is not erased. Verify the memory protection.

The Reading is working fine

[Tesla DeLorean]

Posted on March 17, 2018 at 02:53

So normally you use the standard MX25L512 loader for the STM32F769I-DISCO as they share a common memory and you use the same pins, and 25 MHz HSE?

The default pins get set via stm32f769i_discovery_qspi.c rather than stm32f7xx_hal_msp.c

[boomerblur]

Posted on March 18, 2018 at 08:36

Hi ! Thank you for all your reply. I have been try all of type  IDE such as: KeilV5, EWARM, TrueStudio, with all of ST-Link Ultility  version. But NO things work with me. I try follow example is supply by ST but not success. When I try with 'MX25L512G_STM32F769I-DISCO.stldr' original file supply by ST-Link Ultiliti in External folder It works !!! => My board is OK. What is wrong ? Can ST supply source code of this file in external folder ???

[Tesla DeLorean]

Posted on March 19, 2018 at 18:24

The problem is that it is not written using HAL, or any code publicly released.

I've built an instrumented version using the STM32F769I-DISCO QSPI BSP code, but there are several aspects of that which just don't work properly, or the ST-LINK Utility side times out.

The ST-LINK Utility has access to the Dev_Inf parameters, but doesn't seem to use those to drive requests into the loader, but rather jams things in, writes to RAM, and expects to read from the QSPI in the memory map. The V4.2.0 release for example doesn't expect the Read() interface, but rather than Init() can be called multiple times, sometimes asking for the QSPI to be memory mapped, and others that it not be, and the NOR typically not being programmable while mapped.

Lot of HAL features being used are incompatible with a solution with no interrupts or vector table, etc. Initializing and clearing of statics is broken, but have direction to fix that.

I made a lot of progress yesterday.

[Tesla DeLorean]

Posted on March 21, 2018 at 17:26

Definitely seem to be issues with code size, especially from HAL/CubeMX based BSP code, or ability to instrument. There seems to be a limit of 10 or 12KB in what the ELF Loader can manage.

Not clear what the full expectations are with the loader either. So ST side code fills RAM, and also probes mapped QSPI at 0x90000000. The latter doesn't look to be logged.

Seeing issues here with the utilities calling subroutines in the external loader, as if the debugger can't restart the session after calling into the loader functions, and they change CPU/PLL clocks, QSPI mapping, etc.

Issues loading/executing larger images. Stack size is not specified anywhere, guessing maximal depth of around 250 bytes. Repetitive calling of Init(). New functionality in V4.2.0 where parameter to Init() controls QSPI mapping. Not using Read() functionality. Hard to understand what the man behind the curtain is doing.

Looking for ST Engineers responsible for this product. Please contact off-thread or via

mailto:[e-mail]

Kling.Brian

‌

30183

‌

DAHMEN.IMEN

‌

[Tesla DeLorean]

Posted on March 28, 2018 at 01:48

Going to add a new reply

The Cube Programmer seems to behave a bit differently than ST-LINK Utilities V4.2.0

Additional levels of debug output

Doesn't Interleave Write/Verify operations

Enumerates through .STLDR files, opens them and then has kittens when the 'Internal Name' inside doesn't match up, and tries to load the 'Internal Name'.STLDR and throws errors when that doesn't exist.

The 'Verify After' pulls the ENTIRE image before starting the comparison, so will pull for several minutes only to exclaim there is an error at 0x90000001 or 0x90001000 at the beginning of a 16 or 32 MB image.

Gets in odd states occasionally, resetting the part executing FLASH code on-board

[Buelent Cakir]

Posted on March 28, 2018 at 01:58

one more different what I found out:

It's not possible with the Cube Programmer to trigger other functions in the elf than 'Erase selected Sectors', 'Full Chip Erase' and 'Programming' ( and reading of couse). 

The funny Thing is, that 'Full Chip Erase' is not calling the 'MassErase()'. Instead of that the Cube Programmer is calling erase_Sector() for all sectors from first until last one, and this take more time than a bulk erase on the Flash.

[Tesla DeLorean]

Posted on March 28, 2018 at 03:08

Yes noticed that on the 64MB test on the F769I-DISCO, will special case the full erase when using SectorErase()

The BSP was doing 4KB sector erases, took forever, and think the Cube Prog timed out. The 64KB sector erase work better, but the full erase clearly preferable.

[Imen.D]

Hello,

This issue is faced by developing your own loader with IAR version 8, apparently. This is a known issue came up with the update of IAR.

To fix the issue, you should update the Target.icf file as follow:

define symbol __ICFEDIT_region_RAM_start__ = 0x20000004;

define symbol __ICFEDIT_region_RAM_end__ = 0x21000000;

/*-Sizes-*/

define symbol __ICFEDIT_size_cstack__ = 0x400;

define memory mem with size = 4G;

define region RAM_region = mem:[from __ICFEDIT_region_RAM_start__ to __ICFEDIT_region_RAM_end__];

define region Dummy_region = mem:[from 0 to 0x100];

define block RAM_BLOCK with fixed order {readonly code, readonly data, readwrite };

define block Info_BLOCK with fixed order { readonly data object Dev_Inf.o};

place in RAM_region { block RAM_BLOCK };

place in Dummy_region { block Info_BLOCK };

do not initialize { section .info, readwrite };

Kind Regards,

Imen.

[Tesla DeLorean]

To answer some of the specific questions

1 - No, interrupts and callbacks are not supported. To get callbacks to work you'd need to pump the HAL interfaces as if you had interrupts.

2 - They are not, will typically be whatever you have in ROM/FLASH, I've hard faulted into my own existing routines and dumped telemetry/diagnostic info from there.

3 - Points at whatever, not really usable in this context and probably best left alone

4 - No, you have to make other arrangements to make this work

5 - Yeah, in Keil I use the scatter loader, ST's approach is a hack. I've also built tools to clean ELF files to meet requirements. I created an annealing tool for IAR ELF files, the .ICF above might achieve the desired effect.

I've built a number of working STLDR, such custom work will be expensive, figure minimum several man-days