Skip to main content
EJ.1
EJ.1
Associate II
September 28, 2020
Question

Cannot debug STM32F7508-DK

  • September 28, 2020
  • 3 replies
  • 4602 views

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:

  1. Create touchgfx project for STM32F7508-DK from touchgfx designer 4.14.0
  2. Add simple button or screen and "Generate code"
  3. Browse or import autogenerated "STM32CubeIDE" folder and open project in cubeIDE
  4. Build and debug as "STM32 M-Cortex C/C++ Application"
  5. 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

0693W000004I1GbQAK.png

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

This topic has been closed for replies.

3 replies

Alexandre RENOUX
Alexandre RENOUX
Visitor II
September 29, 2020

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

EJ.1
EJ.1Author
Associate II
September 29, 2020

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:

  1. Firmware must get downloaded to board [OK till here]
  2. Board must auto reset after download complete and debug must halt at main() [Halts at main() but reset FAILS]
  3. 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

Alexandre RENOUX
Alexandre RENOUX
Visitor II
September 30, 2020

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

LMend.3
LMend.3
Associate
July 1, 2021

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.

Tesla DeLorean
Tesla DeLorean
Guru
July 1, 2021

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.

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
LMend.3
LMend.3
Associate
July 2, 2021

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.

PMold.1
PMold.1
Associate II
August 18, 2021

Has this been resolved?

Terms & ConditionsAccessibility statement