• State Not Answered
  • Locked Locked
  • Replies 10 replies
  • Subscribers 21 subscribers
  • Views 2987 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

OS_ERR_FIFO_OVF when CAN data received

ali micro

Hi everybody

I use SAM7x512 and RL-ARM OS.
here, OS has 7 tasks and one of them is for CAN receiver. OS_TICK is 1000 and OS_STKSIZE is 1024. and 500000 is my CAN baudrate(my board is just receiver and transmitter is a KVASER PCI CAN Interface).

speed of data transmission is my problem.

when for example transmitter side of CAN bus send a packet per 10ms or more there is know any problem but when I try to increase the speed after some packet (about 200 messages or more) I will get OS_ERR_FIFO_OVF in os_error function. but when I disable the CAN task all other task are working as well.

note: When the system is getting crash and doesn't do any tasks but it's not in os_error function in debug mode with ulink2 sometimes task of CAN in "RTX task and system" -> "stack load" shows "under flow" and after that it calls os_error (in usual states it's about 3% of stack usage)

I tried such works:

1. increase OS_STKSIZE
2. increase OS_FIFOSZ
3. increase CAN_No_ReceiveObjects
4. chaning the OS_TICK

but nothing happened

Does anyone know what I should do?

Parents
  • 0 in reply to ali micro

    Hi

    after a long while I could found what the problem was.


    * Try to speed up general interrupt handling.

    as you can see in my sample code (2 messages before) the developer of that code has used mailbox to send a new packet to can_receive fuction and can_receive function use mailbox wait to get a new message through OS mailbox

    here I try to omit it and instead, referesh a global variable and flag to be aware in main routine that new message has been received

    everything is OK without any OVF on FIFO; dAbt and pAbt

    I think because the number of intterupts in Ethernet and CAN are too high the only way to cope such a problem is just speed up my ISR routine as Tamir Michael said.

    thanks again

    well done

Reply
  • 0 in reply to ali micro

    Hi

    after a long while I could found what the problem was.


    * Try to speed up general interrupt handling.

    as you can see in my sample code (2 messages before) the developer of that code has used mailbox to send a new packet to can_receive fuction and can_receive function use mailbox wait to get a new message through OS mailbox

    here I try to omit it and instead, referesh a global variable and flag to be aware in main routine that new message has been received

    everything is OK without any OVF on FIFO; dAbt and pAbt

    I think because the number of intterupts in Ethernet and CAN are too high the only way to cope such a problem is just speed up my ISR routine as Tamir Michael said.

    thanks again

    well done

Children
  • 0 in reply to ali micro

    I'm not sure I agree with your analysis. Yes, interrupts should always be as fast as possible. And they should clear out the data and leave the hardware in a stable state. You just may not get your queues full and leave data still in the hardware.

    Another issue the ISR makes use of os_mbx_check() instead of isr_mbx_check().