Cannot debug STM32F7508-DK
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-09-28 12:45 PM
Hello,
I had success in creating and debugging a blinky project when created from cube IDE, but not using touchgfx generated project for this board
I am not able to start a debugging session for project created by touchgfx.
Things I have tried:
1.Explicitly changing to "External loader" from "Debug configuration" corresponding to this board
To recreate this issue:
- Create touchgfx project for STM32F7508-DK from touchgfx designer 4.14.0
- Add simple button or screen and "Generate code"
- Browse or import autogenerated "STM32CubeIDE" folder and open project in cubeIDE
- Build and debug as "STM32 M-Cortex C/C++ Application"
- Wait till target download and click "Resume"
As "Resume" is clicked in debug perspective, after a few seconds the following state is encountered (image) and board stays in blank state forever (LCD white)
Environment:
Windows 10 x64
CubeIDE 1.4.0
CubeMX6.0.1
TouchGFX 4.14.0
MCU PACKAGE FW_F7_V1.15.0
Please help on this issue
Thanks,
Eshwar
Console log
STMicroelectronics ST-LINK GDB server. Version 5.6.0
Copyright (c) 2020, STMicroelectronics. All rights reserved.
Starting server with the following options:
Persistent Mode : Disabled
Logging Level : 1
Listen Port Number : 61234
Status Refresh Delay : 15s
Verbose Mode : Disabled
SWD Debug : Enabled
InitWhile : Enabled
Waiting for debugger connection...
Debugger connected
-------------------------------------------------------------------
STM32CubeProgrammer v2.5.0-RC1
-------------------------------------------------------------------
ST-LINK SN : 066CFF303931594E43082734
ST-LINK FW : V2J37M26
Board : STM32F7508-DK
Voltage : 3.23V
SWD freq : 4000 KHz
Connect mode: Under Reset
Reset mode : Hardware reset
Device ID : 0x449
Revision ID : Rev Z
Device name : STM32F74x/STM32F75x
Flash size : 64 KBytes
Device type : MCU
Device CPU : Cortex-M7
Memory Programming ...
Opening and parsing file: ST-LINK_GDB_server_a09544.srec
File : ST-LINK_GDB_server_a09544.srec
Size : 8356 Bytes
Address : 0x08000000
Erasing memory corresponding to segment 0:
Erasing internal memory sector 0
Download in Progress:
File download complete
Time elapsed during download operation: 00:00:00.403
Verifying ...
Download verified successfully
- Labels:
-
DEBUG
-
STM32CubeIDE
-
STM32F7 Series
-
TouchGFX
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-09-29 7:32 AM
Hello,
First of all, thank you very much for being complete in your request. It happens so rarely that it is extremely appreciated :)
Your step 4 [Build and debug as "STM32 M-Cortex C/C++ Application"] could be the issue. Are you sure you are using the .stldr file when downloading into the board.
To confirm, you could use CubeProgrammer and download into the board selecting the right board and see if it works. Also downloading by clicking on Run Target in the Designer could help to see if the issue comes from CubeIDE.
/Alexandre
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-09-29 12:40 PM
Alexandre,
Thank you for acknowledging :D .
I have concluded that the issue comes form the IDE. Please download and see the attached short videos. I have created them to clearly convey the issue to you.
Video description
video 1 Run target for touchGFX, flashing succeeded, Auto reset [OK]
video 2 flash from cubeProgrammer, flashing succeeded, Auto reset [OK]
video 3 Flash for "Debug as STM32 . . ." option, flash succeeded, No auto reset but needed manual USB disconnect and reconnect. In addition to this, there was debug launch error [NEED SOLUTION]
This is the main issue I am facing.
Ideally when I start debugging, the following should happen:
- Firmware must get downloaded to board [OK till here]
- Board must auto reset after download complete and debug must halt at main() [Halts at main() but reset FAILS]
- Further on clicking "Resume" debug should start and screen will be presented on board [FAILS, instead need manual USB unplug and plug and shows some error related to ExtMem_Boot_Binary]
I have done some findings which I think might be the cause of debug fail
Case1:
When I created project from cubeIDE, debug works. This is because the STM32F750N8HX_FLASH.ld has FLASH and RAM memory definitions exactly as per actual hardware i.e 320kb RAM and 64kb ROM. I am not using this method for integrating with touchgfx because I face FLASH overflow error even if a single screen is created. I this case debug is launching fine until touchGFX is not integrated. After touchGFX integration, flash overflow occurs and build fails. I tried to edit STM32F750N8HX_FLASH.ld to make use of QSPI for touchgfx related assets but failed. So I discarded this way of development. If this could be resolved by your support, I am ok with that. Now lets look at case 2
Case2:
So I created from touchgfx designer, the readymade template to work further. This case did not cause any flash overflow and build also succeeded. But debugging is really an issue. I saw a new folder created by touchgfx generator named "ExtMem_Boot" in project root dir ( ExtMem_Boot APPLICABLE ONLY FOR STM32F7508-DK ONLY)
On opening this folder, I found a readme.txt file. I strongly recommend you to read it. Summary: This is special Firmware developed by ST MCD Application Team to overcome the limitation of low flash capacity devices.
It is my guess that this is interfering with the normal debug launch. I am saying this because the error statement during debug fail "No source available for "_binary_______ExtMem_Boot_Binary_Bootloader_bin_start() at 0x8001ece" shows some relation with the folder "ExtMem_Boot"
Since I have just began working with STM32 platform, This is all I could conclude and provide to you
I request you to resolve any of the above case with this board or if possible, recreate at your end before resolving
Thanks,
Eshwar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-09-30 5:46 AM
You are right, indeed it is currently not possible to debug.
"This is special Firmware developed by ST MCD Application Team to overcome the limitation of low flash capacity devices" so we are not aware of what they did exactly for this part.
FYI, the F750-DK has such small Flash (we consider it Flash-less) that the code needs to be stored in external Flash, therefore outside the MCU.
We will try to investigate and see if we can come up with a workaround.
Sorry for the bother,
/Alexandre
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2021-03-25 6:02 AM
@Alexandre RENOUX​
Is there a way to do this yet? I'm using this same board and cannot debug, exactly the same as @EJ.1​ .
Thanks!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2021-07-01 9:23 AM
Hello All,
this subjet is not resolved ? beacause i have the same problem, i can not communicate with the uart and i would like to debug it but it's not possible the board does not forward in debugging mode..
Lemmy Mendoza.
best regards.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2021-07-01 9:50 AM
Probably need to use debug tools where you can supply a debug script to bring up the QSPI to the point it can be seen in the memory space.
I'd probably avoid the separate boot loader until you have mastered the platform and underlying issue as to why you can't debug it with the tools you have chosen.
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
‎2021-07-02 12:56 AM
Hi,
I'm sorry i'm french and my English it's not very good so i don't sur to understood you very well.
For debug finally i use empiric method with blinking led when my software call the function that i want, it's not very practice and faster but she works :D.
I see new video with stm32H7 disco board on ST youtube the presenter use debugging mode without problem, may be the last cards are more achieve.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2021-08-18 5:29 AM
Has this been resolved?
