• State
  • Locked Locked
  • Replies 12 replies
  • Subscribers 100 subscribers
  • Views 1498 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.

DCAN Interrupt Problem on AM3359

Andreas Andreas
Prodigy 220 points

Other Parts Discussed in Thread: AM3359

DCAN Interrupt Problem on AM3359 although DCANxINT is 0

Hi all,

we have got a huge problem:

We are using the AM3359 with both DCAN interfaces. While communicating via CAN we sometimes have a strange behavior. In case of this failure the value of the DCANxINT register is 0. Although it is 0 the interrupt controller indicates a DCAN Interrupt. Hence the DCAN ISR is again and again called although the DCANxINT register is 0. Because of the recurring ISR no other code is able to execute.

Most of the time the interrupt service routine seems to work correctly. The error case occurs sporadically.

As a workaround in failure case, we set the DCAN controller in init mode, cleared and set the corresponding bit in the interrupt mask register and set the controller back in normal mode. Unfortunately this conclusion did not work.

I added the register view of the failure case. How we can clear the interrupt and how is it possible, that an interrupt is generated although the DCANxINT register is 0?

Does anyone have an idea?

Best regards,

Andreas

  • 0
    TI__Guru**** 393215 points

    Hi Andreas,

    What software are you using?

  • 0 in reply to Biser Gatchev-XID
    Prodigy 220 points

    Hi Biser,

    we are using a custom pcb with a commercial rtos and our application.

    Best regards,


    Andreas

  • 0 in reply to Andreas Andreas
    TI__Guru**** 393215 points

    I'm sorry, we don't support third-party software on this forum.

  • 0 in reply to Biser Gatchev-XID
    Prodigy 220 points

    We do not need any support for a third-party software. We need support for your AM3359 controller. The focus is on the interrupt handling of the am3359. Hence our question is hardware related.

    The question was:

    Why do the interrupt controller of the am3359 signalize an DCAN interrupt, although the registers of the DCAN controller do not signalize any can interrupt?

    I posted the concrete registers of the cpu, the interrupt controller and the dcan controller. How is it possible (in this concrete register configuration), that the interrupt controller means to receive a dcan interrupt? In our opinion, the interrupt controller may not signalize a dcan interrupt (for this register configuration).

    Do you have any idea?

    Best regards,


    Andreas

  • 0 in reply to Andreas Andreas
    TI__Guru**** 393215 points

    I have asked the factory team for support on this.

  • 0 in reply to Biser Gatchev-XID
    Prodigy 220 points
    Hello Biser,

    we don't know your "factory team", but we are looking forward to find a solution.

    How do we proceed, now?

    Best Regards
    Andreas
  • 0 in reply to Andreas Andreas
    TI__Guru* 85865 points
    Hi Andreas
    It will be difficult for us to facilitate debug for a custom board and custom software (even though you have provided a register dump).
    Can you try to run the DCAN starterware example on your board or run your software on a TI platform to see if it helps further isolate the issue?
    If the CAN controller starterware example works, you can compare and contrast the isr and interrupt handling code.
    DO you have any additional pointers in terms of overall interrupt handling in your custom software working ok , for some other peripheral?

    Regards
    Mukul
  • 0 in reply to Mukul Bhatnagar
    TI__Guru* 94181 points
    Hi Andreas, the state you show is definitely strange. Here are a few ideas:
    -When in this state, is there any way to manually clear the interrupt bit. For example, re-read the ES register, toggle the EIE or SIE bits, perform another DCAN init. Just trying to see if the DCAN is in a weird state which is keeping the interrupt active, but not reflecting it in any status bits.
    -Is there anything at a system level you can think of that happened before this state occurred? Maybe the DCAN went into some low power state previous to this, unusual traffic (or lack of traffic) on the DCAN bus. Are you performing any debug access (or connecting with JTAG) at all before the problem occurs?
    -Is it possible that a software interrupt is being triggered (write to INTC_ISR_SETn register) corresponding to that interrupt?

    Regards,
    James
  • 0 in reply to JJD
    Prodigy 220 points

    Hi all!

    @ Mukul

    Our software is very complex and it would take a lot of time to port our sw to another ti platform and vice versa.

    We do have several other peripheral working fine while CAN communication (also interrupt driven).

    @ James

    we already tried to clear the interrupt flag (in different ways) manually while debugging. We also tried to clear it in source code (we catched the strange state and cleared the interrupt pending registers). We even temporally unmasked the interrupt flag in the mask register of the interrupt controller. Unfortunately without success.

    The system runs in a standardized way. It is always the same procedure without any sleep modes or the like. We start the system via I-jet download and run it overnight (without any changes). Perhaps the state is a result of a bad timing? Hard to say, because it is sporadically.

    We do not use any software interrupts.

    We observed a new behavior:

    As an experiment, we switched the interrupt handling from separate to global. If the interrupt controller recognizes a DCAN interrupt on “DCANxCTL-IE0-line” we additionally will lock the global interrupts. Three separate systems run the whole weekend without any failure. With this modification we can observe, that the strange state is not reached, so far. Before changing the interrupt handling the systems reached the state every night.

    Are there any special procedures we have to consider in the dcan interrupt handling?

    Any new ideas?

    Best Regards,

    Andreas

  • 0 in reply to Andreas Andreas
    TI__Guru* 94181 points

    Andreas, i'm not aware of any special handling procedures for interrupts from DCAN. 

    So do you mean that you disable DCAN interrupts (with IEx bit) in your ISR.  So are you essentially disabling nested interrupts?  Or are you disabling all DCAN interrupts with IE0 and IE1?  Would this be an acceptable workaround for you? 

    Regards,

    James

  • 0 in reply to JJD
    Prodigy 220 points

    Hi James,

    you are right, we do not use any nested interrupts.
    Before our modification, we disabled and enabled the dcan interrupts via the IE0 and IE1 registers of each can controller. We do not disable/enable the interrupts directly in the actual dcan isr, but in the dcan driver.

    Now, we do this (in the same places) via the global interrupt enable/disable flag (until now it works). At the moment it would be a temporary workaround, but for the future it would be great to use the separate interrupt lines of the dcan controller (just as it was originally designed).

    This evening we will start another experiment: We will enable/disable the dcan interrupts with IE0 and IE1 as we did before. Additionally we will disable and enable the interrupts in the actual dcan isr. Perhaps the behavior will change (last idea).

    Best Regards,

    Andreas

  • 0 in reply to Andreas Andreas
    Prodigy 20 points
    Hello Andreas,

    Have you found the root cause for the infinite interrupt problem?
    I also encounter the similar problem on AM335x DCAN.

    Best Regards,
    Don