Cant debug cause it works, sic! pls hlp!

ulmus71 wrote on Wednesday, June 06, 2012:

Hi!
I have strange problem with my project. It is quite complicated: i am using 2*uart, dma, i2c, 2*spi, usb and lots of hardware, tasks, queues, semaphores…
and now have problem that when i am running app then it hangs in some place, but when i want to debug then it runs as a charm!!!
Please, do you have any suggestion?

P.S. i am running MPLAB 8.83 and PIC32MX360F512L and FreeRTOS 7.1.1

ulmus71 wrote on Wednesday, June 06, 2012:

I tried to change stack sizes of every task, one by one, and i did! :slight_smile: one of tasks has run out of task space… but… why i couldnt debug it? :frowning: when i debug then i can see that stack has enough space and app works :frowning: strange :frowning:

ulmus71 wrote on Wednesday, June 06, 2012:

I noticed that if i set priority of that task to lowest then app runs with smaller stack size, but when i set priority to higher then i have to increase stack size of that task.

davedoors wrote on Wednesday, June 06, 2012:

it hangs in some place,

Can you narrow that down?

Does everything stop, or just a few tasks or interrupts?

Can you leave stack overflow hooks in your release code (when the debugger is not connected) and turn on an LED, or send a UART message if it gets hit?

ulmus71 wrote on Wednesday, June 06, 2012:

I tried many ways to solve that issue, but nothing… when i debug then all is working, with high and low priority, with minimal stack size. When i run in ‘release’ mode then it hangs, i mean all system hang, i cant get any info but, as you mention, led:) no any uart, spi or something… maybe some uart with dma would work (bypassing software), but i do not want to:)
Now i set proper priority with enough big stack and it works.
I am only wondering, why increasing priority  i have to increase stack size of that task… i thought that if task has higher priority it should get less and less stack size (if there are lots of blocking… things…)

woops_ wrote on Wednesday, June 06, 2012:

Is the compiler optimization changed when running with without debugger?

ulmus71 wrote on Wednesday, June 06, 2012:

hmmm… maybe it is a problem… but i’ve checked now and i have set optimisation to ‘s’, it means to very speedy:) to both: release and debug… i mean, i didnt change optimisation level between compilation types (debug, release).

anonymous wrote on Tuesday, June 12, 2012:

I have the same problem with a PIC32MX250F128D. Runs fine in the debugger, but not in release mode. My system waits forever on a queue that has a 10 mS timeout. It never comes back from the call. I submitted a new request yesterday but haven’t heard anything back yet. I’m curious to know which aspect of FreeRTOS would be sensitive to a release build vs a debug build. It seems that you have already tried adjusting the task stack sizes to no avail. I’ve stripped out almost all of my code to just toggle an LED in the loop that contains just an xQueueReceive call with the 10 mS timeout. Just a note, the S optimization option is mainly for size, not speed. It only uses certain speed optimizations if the size is not affected.

davedoors wrote on Tuesday, June 12, 2012:

I submitted a new request yesterday but haven’t heard anything back yet

To who?  Is this the reply you didn’t receive? (post 3) https://sourceforge.net/projects/freertos/forums/forum/382005/topic/5341856