Crazy Long delays when debug stepping

Follow

Ms115

• March 27, 2019 10:39
• Edited

Hi,

I'm experiencing 3-5 second delays when debug stepping.

This is seen right at the start at reset handler stepping the very first instructions in the disassembly window -so it cant be anyting to do with the actual apps runtime operation.

Im using TouchGFX and CubeMX to generate the code. TouchGFX seems to need the external tool chain - using their version of GCC - so the crossworks options are set for this. Also as its an external build, I need to use an external load file (application.ld) as generated by TouchGFX. - so with this, Ethernet memory placement issues, and other bits, its a complicated build environment.

I've tried this on STs F769Disco and the F746Disco boards and get the same results. Im using the built in STLink with latest drivers and versions of  all software.

However if I build a project without ToughGFX (but using their application.ld file)then I dont get these debug delays.

I've played arround will the obvious crossworks debug options, release/debug builds and memory placement in the .ld file etc but to no avail - (over several days!!).

Any ideas?

thanks

Mark

 

0

• 

  Markus

  • April 01, 2019 07:09

  Hello Mark,

   

  the onboard-JTAG Adapters are rather slow. If you have opened several register- and memory-watch windows this could slow down the stepping. All this Values are reloaded at each step. If the JTAG-Connection is slow, you can face these long delays.

  Just an Idea.

  Regards

  Markus

   

  0

  Comment actions Permalink
• 

  Ms115

  • April 01, 2019 21:09

  Markus,

  
  I think you may be right,

  
  Crossworks’s Michael suggested I delete the .hzs file. I was convinced I had done this more than once (as you prob know this is where this stuff is held). But I guess I hadn't, as it fixed it (doh).

  
  I had this issue for several days and tried all sorts of things – Making the STLink use JLink drivers, even converting the project to TrueStudio (yes I know - but I was desperate).

  
  I’m not sure what the .hzs file held that was causing problems, but it may well have been memory watch stuff (hiding from me somehow!)

  
  …. now off to delete the TrueStudio version of my project :)

  Thanks
  Mark

  0

  Comment actions Permalink
• 

  Daniel Pfeil

  • July 17, 2019 13:02
  • Edited

  Hello,

  I'm also trying to build a TouchGFX project in Crossworks. Therfore I use the TouchGFX GCC toolchain in Crossworks.

  I get the following compile errors when compiling the FreeRTOS source file port.c:
  
  
  
  Do you have any idea?

  0

  Comment actions Permalink
• 

  Michael Johnson

  • July 17, 2019 06:33

  Try setting the Floating Point ABI to Hard

  Regards

  Michael

  0

  Comment actions Permalink
• 

  Daniel Pfeil

  • July 17, 2019 13:01
  • Edited

  Hi Michael,

  thank you for your response!

  Setting the floating point to hard solves the compile error above but brings up a lot of link errors:

  

  I think there are this link erros because the TouchGFX lib was built with soft floating point unit.

  0

  Comment actions Permalink
• 

  Michael Johnson

  • July 17, 2019 09:23

  There are two libraries

  libtouchgfx.a and libtouch-float-abi-hard.a

  use the latter one.

  Regards

  Michael

  0

  Comment actions Permalink
• 

  Daniel Pfeil

  • July 17, 2019 13:00
  • Edited

  Hi Michael,

  thank you, now I can build the project, but I'm not able to debug with crossworks as I get the following error when I start debugging (pressing F5).

  

  I think the problem is the external flash. Do you have any idea?

  0

  Comment actions Permalink
• 

  Michael Johnson

  • July 17, 2019 13:05

  You may need to set the size of the QSPI memory in the "Memory Map Macros" property

  QUADSPI_FLASH_SIZE=0x01000000

  and a board specific loader will be required. This can be done by setting the "Project Macro" property

  LOADER=$(TargetsDir)/ST_STM32F746G_DISCOVERY/Loader.elf

  Regards

  Michael

  0

  Comment actions Permalink
• 

  Daniel Pfeil

  • July 17, 2019 14:35

  Now I use this loader: LOADER=$(TargetsDir)/ST_STM32F769I_DISCOVERY/Loader.elf

  With this loader every second time everything works fine (also the external flash can be earsed and programmed).

  But every second time the loader hangs up (loader exit timed out) when erasing the external flash.

  Do you have any idea?

  

  0

  Comment actions Permalink
• 

  Michael Johnson

  • July 18, 2019 08:28

  I'd guess there are reset issues with the external flash.

  If this is a effectively a one-time process, e.g. to store data tables, you can use the "No Load Sections" project property to avoid programming this each time.

  0

  Comment actions Permalink

Please sign in to leave a comment.