Forums

Debugging with FreeRTOS

Started by sig5534 August 24, 2008
This is my first time doing an MCU with an RTOS, so perhaps this is
something simple:

- I have an LPC2468 design. FreeRTOS running, LEDs blinking as
expected after program is loaded and is running normally.

- When I Stop/Pause the MCU with the debugger, and then start it with
GO again, no more LEDs blinking. FreeRTOS seems to have been
bothered by stopping the processor.

- Then when I stop the MCU again, send it to 0x200 for a Restart,
FreeRTOS is still not running right. Only if I do a Hardware RESET
does everything start working again.

(a) What is bothering FreeRTOS by stopping the processor?

(b) What registers are still not being initialized again by going
back to 0x200? It still requires a full hardware reset to go again.

Thanks, Chris.

An Engineer's Guide to the LPC2100 Series

> This is my first time doing an MCU with an RTOS, so perhaps
> this is something simple:
>
> - I have an LPC2468 design. FreeRTOS running, LEDs blinking
> as expected after program is loaded and is running normally.
>
> - When I Stop/Pause the MCU with the debugger, and then start
> it with GO again, no more LEDs blinking. FreeRTOS seems to
> have been bothered by stopping the processor.
>
> - Then when I stop the MCU again, send it to 0x200 for a
> Restart, FreeRTOS is still not running right. Only if I do a
> Hardware RESET does everything start working again.
>
> (a) What is bothering FreeRTOS by stopping the processor?
>
> (b) What registers are still not being initialized again by
> going back to 0x200? It still requires a full hardware reset
> to go again.

Which compiler, debugger and debug interface are you using?

I have probably used every combination of ARM compiler and debug interface
imaginable and never come across a problem like that - have you confirmed
that you are able to stop and start a program that does not use FreeRTOS.org
when that program uses a timer interrupt?

Regards,
Richard.

+ http://www.FreeRTOS.org
17 official architecture ports, more than 6000 downloads per month.

+ http://www.SafeRTOS.com
Certified by T as meeting the requirements for safety related systems.

> Which compiler, debugger and debug interface are you using?

GNUARM, Signum JetJTAG / Chameleon Software Debugger.

> have you confirmed that you are able to stop and start a
> program that does not use FreeRTOS.org when that program
> uses a timer interrupt?

Well this project was started with FreeRTOS so that's the only code I
have run on it right now. On my previous LPC2104 and LPC2132 designs
that did not use any RTOS, I never had a problem stopping/starting
execution like this with the same dev setup. They all used Ints/ISRs
of various kinds.

What about Supervisor vs. User modes? All my other programs probably
ran in Supervisor mode all the time. You do a switch don't you?

If the code gets restarted back at 0x200 will it be in Sup or User
mode? Does it need to be back in Sup mode?

What about when the debugger cuts in and breaks execution? Could
that cause some kind of mode change that is bothering FreeRTOS?

Chris.

> > Which compiler, debugger and debug interface are you using?
>
> GNUARM, Signum JetJTAG / Chameleon Software Debugger.
>
> > have you confirmed that you are able to stop and start a
> program that
> > does not use FreeRTOS.org when that program uses a timer interrupt?
>
> Well this project was started with FreeRTOS so that's the
> only code I have run on it right now. On my previous LPC2104
> and LPC2132 designs that did not use any RTOS, I never had a
> problem stopping/starting execution like this with the same
> dev setup. They all used Ints/ISRs of various kinds.
>
> What about Supervisor vs. User modes? All my other programs
> probably ran in Supervisor mode all the time. You do a switch
> don't you?
>
> If the code gets restarted back at 0x200 will it be in Sup or
> User mode? Does it need to be back in Sup mode?
>
> What about when the debugger cuts in and breaks execution?
> Could that cause some kind of mode change that is bothering FreeRTOS?

A FreeRTOS.org app is just like any other C app with very few hardware
dependencies. It does nothing special or unexpected itself. Tasks run in
System mode and the kernel in Supervisor mode, but the debugger should not
care about that.

When restarting a paused program the debugger should leave the execution
context exactly as it found it, and as Chameleon is a mature product I
cannot imagine it has any fundamental issues with regards to that, so it
must be something more subtle.

FreeRTOS.org uses a timer interrupt and the software interrupt. On the
assumption that the timer interrupt is just bread and butter to the debugger
I would look to the software interrupt as a possible source of the problem.
Does the debugger use the SWI vector itself?

With regard to restarting the app by pointing the program counter to 200 -
if this is all that is done and there is no form of hard or soft processor
reset then there is no reason why restarting the program in this manner
would fix the problem.

Once the problem has occurred, what does the FreeRTOS.org application do?
If you stop the app running again does it look like the same task is just
continuously running, or does it crash big time? Can you determine if the
timer interrupts are still functioning as without the timer tick nothing
will happen.

Regards,
Richard.

+ http://www.FreeRTOS.org
17 official architecture ports, more than 6000 downloads per month.

+ http://www.SafeRTOS.com
Certified by T as meeting the requirements for safety related systems.

>> Does the debugger use the SWI vector itself?

Don't know.

>> Once the problem has occurred, what does the FreeRTOS.org application do?

Code is still running, not in weeds. Seems to go in the CriticalExit routine a lot.

>> If you stop the app running again does it look like the same task is just continuously running, or does it crash big time?

Might be same task running.

>> Can you determine if the timer interrupts are still functioning as without the timer tick nothing will happen.

Seems like all INTs are down after pause.
Also, when I start the app from hard reset it is running with slow LEDs. But after a cuple minutes LEDs blink fast. This is supose to be your error indication. Seems to be a memory error tripping it I think. Not sure what that is from.

Chris.

> >> Does the debugger use the SWI vector itself?
>
> Don't know.

Maybe their tech support could shed some light on this.
>
> >> Once the problem has occurred, what does the FreeRTOS.org
> application do?
>
> Code is still running, not in weeds. Seems to go in the
> CriticalExit routine a lot.
That would be a symptom of interrupt not running.

> >> If you stop the app running again does it look like the
> same task is just continuously running, or does it crash big time?
>
> Might be same task running.
>
> >> Can you determine if the timer interrupts are still
> functioning as without the timer tick nothing will happen.
>
> Seems like all INTs are down after pause.

Hmm. As above. As I said before, FreeRTOS.org apps are just like any other
app, so I don't see why anything should be any different.

Regards,
Richard.

+ http://www.FreeRTOS.org
17 official architecture ports, more than 6000 downloads per month.

+ http://www.SafeRTOS.com
Certified by T as meeting the requirements for safety related systems.

>> That would be a symptom of interrupt not running.

I figured it out. I remember I had this happen a long time ago. I had IR
status registers displayed. When those are displayed, stopping execution
causes the IR regs to be read for display, which clears the INTs. That
kills the INTs. That was the problem.

so as you say it , the leds may blink again after continue the program,but in sjg5534's case , no more LEDs blinking









´ϻbr />
2008-08-25







HM2

ʱ䣺 2008-08-25 07:29:27

l...



Re: [lpc2000] Re: Debugging with FreeRTOS



>> That would be a symptom of interrupt not running.



I figured it out. I remember I had this happen a long time ago. I had IR

status registers displayed. When those are displayed, stopping execution

causes the IR regs to be read for display, which clears the INTs. That

kills the INTs. That was the problem.