Debug External memory code execution on STM32F7x0 Value line with SW4STM32
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-07-10 1:34 PM
How can I debug a program that is being loaded and running from the QSPI external memory of the STM32F750 using the XiuP model?
- Labels:
-
SW4STM32
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-07-10 2:40 PM
Can't your tools do that now?
Do you need a debugger script to set up the memory interface properly? An external loader to support the memory on your board?
Sort of thing you're expected to do in Keil and IAR
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
‎2019-07-10 10:53 PM
I'm not sure I fully got you.
This is the case:
- I have a running project that I build and load its hex file to QSPI @ 0x90000000 with STM32CubeProgrammer and then I load from within a debug session under SW4STM32 the ExtMemBoot that was build with USE_INTERNAL_SRAM & USE_QSPI through.
- When I step through the main of the ExtMemBoot all is fine but when I try to see and set breakpoints to code that is a pat of the external QSPI then the debugger of course does not "know" about it as it was built from with in another project.
- In AN5188 it says:
The XiP model provides a seamless load and debug experience similar to an internal Flash debugging. For
SW4STM32 IDE, the STM32CubeProgrammer should be used for application loading on external Flash
memories.
Given of all that, how can I perform this debug session?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-07-13 12:22 AM
Not sure what you mean precisely, but: You *build* the project with SW4STM32 and only program the image with STM32CubeProgrammer?! So actually it's build with gcc and debugged by gdb, that should be no problem as long as it's built with the appropriate debug symbols ("-g" should be sufficient). And even single-stepping through the parts in external memory should work "out of the box". Breakpoints are different though. In external merory you have to use 'hardware breakpoints', as gdb doesn't know how to erase/program the external memory (which would be required for 'software breakpoints').
hardware breakpoints: use address comparators inside the chip's debug interface, hence limited in number
software breakpoints: breakpoint instruction is placed into program code, requires reprogramming of program code
As I don't use SW4STM32, I can't tell you how to use hardware breakpoints by default there, you've to search the relevant docs.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-07-13 12:26 AM
Forgot to mention: probably it's sufficient to add a suitable option to one of gdb's init files (.gdbinit or similar), but where to place this file and other details I don't know.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-07-13 12:48 AM
Thank you Andreas for your answer.
The issue is that since I'm running my target project from the external QSPI flash in XiP mode I need to create a separated boot program that enable the QSPI and set it to memory mapped mode and then jump to the starting point of the main program in the QSPI (That was pre loaded to the QSPI by using the programmer)
The boot program is the one that is being loaded and running from the debugger and my question refer to how can I step\breakpoint the main program that is actually not loaded currently in the debugger.
