Debug single step painfully slow with FreeRTOS running.

Follow

Mark

• September 19, 2015 19:18

Hi,

I've noticed that single stepping debug with FreeRTOS running is painfully slow. (ie 1 second per step)

Up until the point that FreeROTS starts everything is fine (almost instant) , but after osKernelStart()  is called it goes slow.

There is only 1 FreeRTOS task and this is simply toggling an LED!

FYI. It seems to happen after the call to prvPortStartFirstTask() in port.c.

Tried it on F4Discovery and F7Discovery boards, and on different (Win7) machines.

Crossworks and libs are latest,  as is freeRTOS (v8.2.1). STLink has the latest firmware too.

Any ideas?

Cheers

Mark.

(PS sadly, cant use CTL for this project, cos of 3rd party libs)

0

• 

  Luke Jeanmaire

  • September 24, 2015 12:45

  Do you have a long list of variables that is being updated with each step?  If I have the global variables window showing in our freeRTOS projectes, single step takes a very long time.

  Luke

  0

  Comment actions Permalink
• 

  Mark

  • September 28, 2015 10:04

  Thanks for the reply,

  But, no variables window (or anyothers for that matter)

  Anyway, if I did, how would this slowdown the debugging only AFTER FreeRTOS starts up (since these variables would be uploaded regardless of the RTOS state)... 

   

   

  0

  Comment actions Permalink
• 

  Luke Jeanmaire

  • September 28, 2015 12:39

  Sorry my suggestion was not helpful.  I would not expect debugging to be impacted by FreeRTOS starting up.

  0

  Comment actions Permalink
• 

  Mark

  • September 28, 2015 14:30

  Luke,

  ok, its getting worse!

  I can stop the issues by turning off Level 2 optimisation in the FreeROTS libraries; debugging step speed is then fine before and after FreeRTOS starts.

  Bit confused at the mo as other probs arrising with "DEV_TARGET_CMD_ERR" and loss of debug connection to the target, when I turn optimisation back on.

  Might just be down to my dodgy code...  will update as I find out more.

   

   

  0

  Comment actions Permalink
• 

  Michael Johnson

  • September 28, 2015 16:36

  I suspect the "DEV_TARGET_CMD_ERR" is due to the debugger accessing memory that doesn't exist - try setting the "Restrict Memory Acceses" project property see if this helps.

  0

  Comment actions Permalink
• 

  Mark

  • October 05, 2015 08:19

  Michael, your suspicions were right - thanks.

  Is this related to a bug/config issue in my project?  Why would the optimisation of just the FreeRTOS libs make this occur?

  BTW, Still don’t know why the single stepping issue has gone; I’ll revert to a backup to see if it still there!

  0

  Comment actions Permalink
• 

  Michael Johnson

  • October 05, 2015 08:30

  The default is to restrict memory accesses. However we may not have covered all the valid address spaces in the memory map file (this would cause peripheral registers to be read as 0xfefefefe) so you may have switched this off. The problem is backtracing out of FreeRTOS tasks - the debugger would stop at 100 backtraces on each single step.

  0

  Comment actions Permalink

Please sign in to leave a comment.