[feature] Programming external Quad SPI flash not supported
rahmanih opened this issue · comments
Hi,
I've downloaded the touchgfx (http://touchgfx.com) evaluation version and I'm trying to test it on the F746.
STMF746 Discovery Kit,
http://www2.st.com/content/st_com/en/products/evaluation-tools/product-evaluation-tools/mcu-eval-tools/stm32-mcu-eval-tools/stm32-mcu-discovery-kits/32f746gdiscovery.html
I've followed the README guilde on how to flash the, everything seems working, below the log of the "st-util"
2016-05-13T11:50:31 INFO src/stlink-common.c: Loading device parameters....
2016-05-13T11:50:31 INFO src/stlink-common.c: Device connected is: F7 device, id 0x10016449
2016-05-13T11:50:31 INFO src/stlink-common.c: SRAM size: 0x50000 bytes (320 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 2048 bytes
2016-05-13T11:50:31 INFO gdbserver/gdb-server.c: Chip ID is 00000449, Core ID is 5ba02477.
2016-05-13T11:50:31 INFO gdbserver/gdb-server.c: Target voltage is 3226 mV.
2016-05-13T11:50:31 INFO gdbserver/gdb-server.c: Chip clidr: 09000003, I-Cache: off, D-Cache: off
2016-05-13T11:50:31 INFO gdbserver/gdb-server.c: cache: LoUU: 1, LoC: 1, LoUIS: 0
2016-05-13T11:50:31 INFO gdbserver/gdb-server.c: cache: ctr: 8303c003, DminLine: 32 bytes, IminLine: 32 bytes
2016-05-13T11:50:31 INFO gdbserver/gdb-server.c: D-Cache L0: 2016-05-13T11:50:31 INFO gdbserver/gdb-server.c: f003e019 LineSize: 8, ways: 4, sets: 32 (width: 10)
2016-05-13T11:50:31 INFO gdbserver/gdb-server.c: I-Cache L0: 2016-05-13T11:50:31 INFO gdbserver/gdb-server.c: f007e009 LineSize: 8, ways: 2, sets: 64 (width: 11)
2016-05-13T11:50:31 INFO gdbserver/gdb-server.c: Listening at *:4242...
2016-05-13T11:50:59 INFO gdbserver/gdb-server.c: Found 8 hw breakpoint registers
2016-05-13T11:50:59 INFO gdbserver/gdb-server.c: GDB connected.
2016-05-13T11:51:09 INFO src/stlink-common.c: Attempting to write 32768 (0x8000) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08000000 erased
2016-05-13T11:51:10 INFO src/stlink-common.c: Finished erasing 1 pages of 32768 (0x8000) bytes
2016-05-13T11:51:10 INFO src/stlink-common.c: Starting Flash write for F2/F4/L4
2016-05-13T11:51:10 INFO src/stlink-common.c: Successfully loaded flash loader in sram
enabling 32-bit flash writes
size: 32768
2016-05-13T11:51:10 INFO src/stlink-common.c: Starting verification of write complete
2016-05-13T11:51:10 INFO src/stlink-common.c: Flash written and verified! jolly good!
2016-05-13T11:51:10 INFO src/stlink-common.c: Attempting to write 32768 (0x8000) bytes to stm32 address: 134250496 (0x8008000)
Flash page at addr: 0x08008000 erased
2016-05-13T11:51:10 INFO src/stlink-common.c: Finished erasing 1 pages of 32768 (0x8000) bytes
2016-05-13T11:51:10 INFO src/stlink-common.c: Starting Flash write for F2/F4/L4
2016-05-13T11:51:10 INFO src/stlink-common.c: Successfully loaded flash loader in sram
enabling 32-bit flash writes
size: 32768
2016-05-13T11:51:11 INFO src/stlink-common.c: Starting verification of write complete
2016-05-13T11:51:11 INFO src/stlink-common.c: Flash written and verified! jolly good!_
but the content displayed on the LCD is scrambled.
I think the issue is not related to the stlink tool st-util because it has flashed correctly. Probably you have not flashed the correct file or timing set incorrect? It could also the problem there are some internal clocks or registers reconfigured/reset during programming with st-util which screws up the demo app.
Could you try with OpenOCD 0.9.0 or higher?
same issue with openOCD,
the example I'm using is the following:
https://github.com/draupnergraphics/touchgfx-open-repository/blob/master/app/tutorials/01_hello_world
it's link file is the following:
https://github.com/draupnergraphics/touchgfx-open-repository/blob/master/app/tutorials/01_hello_world/target/ST/STM32F746G-DISCO/gcc/application.ld
The LCD driver has nothing todo with the stlink project or openocd programming. You should try to flash a led blink test with one of the stlink tools and see if it works.
using the ST-Link utility downloaded from the st.com website, the same binary file is working correctly.
but I had to enable the load from external flash.
does the stlink support such an option?
There is no external flash loader currently in the stlink project, and is highly target/board specific. Your display was scrambled before because the flash had no sprites loaded into the external Quad SPI Flash.
For OpenOCD they have already written a patchset to support programming external quad spi flash. But it has not been merged yet: http://openocd.zylin.com/#/c/3162/
If someone finds time to do it, I would really like if the implementation was compatible with STM32 ST-Link utility. The benefit would be the ability to use the ST-LINK provided .stldr files (they are just elf files that load to RAM, providing unified functions) - this would be especially useful as it would allow to use the loaders that ST develops and distributes in future STM32 ST-LINK Utility. Some might oppose to using binary blobs (on various merits), however it should be noted that making it compatible with stldr files does not require the use of the files from ST-LINK Utility - it only enables the possibility to do so. I don't think there's any need to implement yet another (incompatible) interface for the external loaders.
@tarek-bochkati: I've noticed your activity around this topic on https://github.com/STMicroelectronics/OpenOCD. Would you be interested in helping us along with this as well?
@Nightwalker-87
Hi,
I have started by reading this thread from the beginning (started by one of my colleagues BTW).
let me start by the current status, in OpenOCD: #3162 is replaced by #4321 and the later was cherry-picked in ST-OpenOCD
but this is quite different as the flash algo in OpenOCD is circular continuously fed FIFO,
versus, ST-Link UTILITY and STM32CubeProgrammer as well the algo is as simple as a straight linear algo.
and BTW, IDK flashloader in STM32CubeProgrammer are distributed in which license, so reusing the same stldr files may not be possible if the license does not allow it.
I'm not an expert in license stuff, maybe you can help, or we can gently ask here and there.
Please give me time to better understand this project structure, and then I will be able to propose something regarding the external flash programming.
@tarek-bochkati: Thx for your feedback. Because we are licensed under BSD-3 (clean), we would need to ensure that there is no license conflict with OpenOCD and its derivatives, which are under GPLv2. As the implementation of the flash algorithm is different, this would have not been an option anyway.
@Ant-ON: Can you give a short summarised feedback on this issue and state whether it could be of any further relevance?
@Nightwalker-87 External memory (connected via SPI) flashing has not yet been implemented. I doubt that in the near future someone will undertake this
@Ant-ON The question is if it is desirable and whether it would be of any broader interest, but to me this reads like a "Not really"...
@Nightwalker-87 This is a narrow problem and not everyone needs it
Closed due to inactivity and very rare interest.