[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

[Tesla DeLorean]

Posted on March 18, 2018 at 05:55

Second Attempt, adjustments for S25F128L

________________ Attachments : N25Q128A-STM32F446-CUSTOMBOARD-002.stldr.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Hxi4&d=%2Fa%2F0X0000000b1k%2FPZ0HBagZ0R6wVTPB72IbcoWXGgwXsqZlUNngXtVyCvI&asPdf=false

[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:sourcer32@gmail.com

Kling.Brian

‌

30183

‌

DAHMEN.IMEN

‌

[Tesla DeLorean]

Posted on March 21, 2018 at 23:40

Also this type of nonsense in all the Verify examples, returning entirely the wrong address for the miss-match

  while (Size>VerifiedData)

  {        if ( *(uint8_t*)MemoryAddr++ != *((uint8_t*)RAMBufferAddr + VerifiedData))            return (MemoryAddr + VerifiedData);

        VerifiedData++;

  }

Tip: You're incrementing both these variables, return(MemoryAddr - 1) would be what you want

[Tesla DeLorean]

Posted on March 22, 2018 at 08:46

It has also dawned on me that if you are resetting the CPU then code I have in FLASH might be trashing RAM, ie initial SP, or statics. I've seen my FLASH based Hard Fault code throw diagnostics on a couple of occasions. KEIL based code can have SP in lower memory.

[Tesla DeLorean]

Posted on March 22, 2018 at 13:43

Ok, that didn't help.

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