[Error] Building a custom external loader for a custom board based on a STM32F7 MCU
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2018-03-14 08:20 PM
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- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2018-03-17 10:55 PM
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=falseUp vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2018-03-18 12:36 AM
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 ???
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2018-03-19 11:24 AM
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.
Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2018-03-21 10:26 AM
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
‌Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2018-03-21 04:40 PM
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
Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2018-03-22 01:46 AM
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.
Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2018-03-22 06:43 AM
Ok, that didn't help.
Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2018-03-27 04:48 PM
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
Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2018-03-27 06:58 PM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2018-03-27 08:08 PM
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.
Up vote any posts that you find helpful, it shows what's working..