freeRTOS, LPC2129 and CAN problem

nobody wrote on Friday, September 16, 2005:

Anyone uses the freeRTOS with philips uC with a CAN application.

I have a problem, that the CAN very often gets an error for "Data Overrun", that is that the controller doesnt have time to read out the CAN rx interrupt before a new message comes. This is not good in my application becourse its a very critical on communication.

Anyone here knows anything about this problem?

And a question about freeRTOS, is the IRQ disabled in the core for longer time during contex switches etc??

Pls help me!


rtel wrote on Friday, September 16, 2005:

The scheduler locking mechanism within the FreeRTOS kernel implementation along with the small code size means interrupts are disabled less often than with comparable RTOS implementations.  However some overhead is unavoidable.  Here are some notes:

+ Dont have the tick frequency any faster than necessary.  See configTICK_RATE_HZ within FreeRTOSConfig.h.

+ Use the queue/semaphore mechanisms within ISRs sparingly, only where really necessary.  The serial port demo drivers make heavy use of these functions primarily to test their functionality.  A faster ISR can be created by using the ISR to place received data within a simple circular buffer, then simply waking the task that is to process the characters.

+ Dont make a queue or semaphore function call on every received byte.  Instead make the call at the end of the frame, or at the end of the ISR if multiple bytes are received within a single ISR.

+ Use of the kernel means the ISR can be kept really short, just buffer the data and clear the interrupt.  Let a task do any further processing required.

+ Stating the obvious, how your application uses interrupts will make a difference.  Dont have lots of code within ENTER/EXIT_CRITICAL sections.  If you dont want the scheduler to run while you access something use scheduler suspends and resumes instead.  This way interrupts remain enabled.

I have had interrupt driven serial comms, USB comms and Ethernet comms running simultaneously with no problem but have not tried the CAN.  However, should it become necessary you could implement some interrupt nesting  although this is a bit more tricky on ARM.

How fast are you running the processor?  What baud rate are you using?  Does the LPC interrupt on every frame, or every byte?


nobody wrote on Friday, September 16, 2005:


Thanks a lot for your answer.
I had a semaphore in the CAN ISR routine but I tried to take it away. Now I just save the recieved message in a buffer and clearing the interrupt. I have a task that run and checks if there is something in the buffer.

But this didnt help, I’m not sure if its the RTOS or the uC that makes this error, so im just gonna contiue to se if I can understand it.

BTW, I have a uart implementation that uses semaphore and it is working with no problem.


imajeff wrote on Friday, September 16, 2005:

Fine to hear that the semaphore in your uart implementation is working, but realize that this could be your problem if it stops you from receiving a CAN message while waiting to manipulate the semaphore.

nobody wrote on Friday, September 16, 2005:

Don’t follow this.  Can you explain more?

nobody wrote on Wednesday, September 21, 2005:

There is a problem with the LPC2129 CAN bus. check the philips web site for the erata.