• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 32 subscribers
  • Views 528 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

FlexRay - every third interrupt not generated

Martin Zeman
Intellectual 820 points
Other Parts Discussed in Thread: TMS570LS3137

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

  • 0
    TI__Guru 59540 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

  • 0
    TI__Prodigy 260 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
  • 0 in reply to Peter Steffan
    Intellectual 820 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...

  • 0 in reply to Martin Zeman
    TI__Guru 59540 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.