FlexRay - every third interrupt not generated - Hercules™ Safety Microcontrollers Forum - Hercules™ Safety Microcontrollers

FlexRay - every third interrupt not generated

This question is not answered

Posted by Martin Zeman

on May 03 2012 13:10 PM

Hello,

I'm handling interrupts generated by FlexRay controller at the start of a FR frame. My handler is set as FIQ. The problem is that for some reason every third FR cycle the interrupt is not generated. Sometimes it leaves out even more often. I have no other interrupts set as FIQ, so it should always have a top priority. I have checked that all the frames in all the cycles are succesfully trasmitted on the bus. Here is a sample of my code:

The FR interrupt handler is in one .c file:

#pragma INTERRUPT(FR_interrupt, FIQ)
void FR_interrupt(void){
clear_status_interrupt_register();
FR_rcv_flg = 1U;
}

The ISR is in another:

while (running) {
           lwipPeriodicHandle(s_timestamp);

           if (FR_rcv_flg) {
               FR_to_udp();
           }

           if (eth_rcv_flg) {
               decode_udp_runtime();
           }
       }

I know for a fact that every interrupt which is generated is also serviced in "FR_to_udp()" so the problem lies in the interrupt not being generated at all. Does anyone have an idea what might be causing this?

Best regards

Martin

All Replies

Posted by Chuck Davenport

on May 03 2012 13:19 PM

Expert6445 points

Hello Martin:

In order to try and help you get a quick resolution to your issue with the FlexRay interrupts, I am forwarding your post to our FlexRay expert. He should respond shortly.

Regards,

Chuck Davenport

Thanks and Regards,

Chuck Davenport

If this response answers your question, please indicate it by verifying the suggested answer when provided.

Posted by Peter Steffan

on May 04 2012 04:20 AM

Prodigy185 points

Hello Martin,

From the FlexRay hardware perspective we never saw missing start of cycle interrupts.
From the code you provided, I could think of 2 possible causes for the issue you see:

1. CYCS flag (bit #2) in the SIR (Status Interrupt Register) does not get cleared properly:
When looking to your interrupt handler I assume that you are clearing the CYCS flag (bit #2) in the SIR (Status Interrupt Register) in the function clear_status_interrupt_register(); Correct?
Are you sure the flag always gets cleared properly in this subroutine? Since the clearing of one flag can be done in one simple C instruction, I would propose to remove the function call and clear the CYCS flag directly with one instruction in the interrupt handler.

2. FR_to_udp() does not always get entered after a start of cycle interrupt:
What concerns me more is the line FR_rcv_flg = 1U; in the interrupt handler, where you set a 'marker' to enter FR_to_udp() later in the ISR. I can not see in your code the exact point where you reset FR_rcv_flg back to 0, but I am sure you do it somewhere.
However, in case

this would happen too late, after the next start of cycle interrupt occurs, or
FR_rcv_flg would get corrupted due to any reason (variable unexpectedly gets overwritten, i.e. by a stack overrun or an incorrect pointer),

then the code might not always enter FR_to_udp(). This could, by mistake, be interpreted as a not generated start of cycle interrupt.

Best Regards,
Peter Steffan

Posted by Martin Zeman

on May 04 2012 07:18 AM

Prodigy135 points

Hello Peter,

thanks for your suggestions, however I'm not using the start of cycle interrupt but the received frame interrupt. The function clear_status_interrupt_register() indeed does nothing else but clear the whole SIR like this:

void clear_status_interrupt_register(void){
frayREG->SIR_UN.SIR_UL = 0xFFFFFFFF;
}

Clearing right in the interrupt handler is a good idea, thanks for the suggestion, but it didn't prove to be the cause. After doing some testing I can rule out that FR_to_udp() not entered. Every time an interrupt is generated it is also serviced in FR_to_udp(). The FR_rcv_flg gets reset the first thing in the FR_to_UDP().

I'm starting to think that the problem might have to do with some of the FR controller parameters. I have 2 nodes with freescale controllers whose parameters are known to me, so I set my tms570ls3137 E-ray controller according to those parameters. I presumed that the parameters are flawless, which they might be, I'm just not certain. The only thing that comes to my mind right now is that the rate correction is applied in every third cycle. That might have something to do with it...

Posted by Chuck Davenport

on Dec 19 2012 14:00 PM

Expert6445 points

Hello Martin,

As of your last posting, it seems you were still having some issues with your FlexRay setup. Were you able to resolve your issue? If so, it might be helpful if you could post your final resolution or simply that it was resolved. If you still need additional help on this topic, please let us know.

Thanks and Regards,

Chuck Davenport

If this response answers your question, please indicate it by verifying the suggested answer when provided.