• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 31 subscribers
  • Views 341 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.

TMS570LS3137: DCAN Interrupt fired when interrupts are deactivated.

Anudeep Varada
Prodigy 102 points

Part Number: TMS570LS3137
Other Parts Discussed in Thread: HALCOGEN

Tool/software:

Hello

We noticed a behavior that, when a CAN message is received at the power ON an interrupt is fired. The INT register value read in the ISR is 0.

I tried to disable the IE0 and IE1 bit in CTL register at bootup and activate it only later, still the interrupt is fired. please find the screenshot of the register values in ISR.

 

I additionally tried to keep the CAN in initialization mode, Interrupt was fired in initialization mode as well. 

The value 0 of INT register means no pending interrupts correct? then why did the ISR was called? 

Does the value 0 in INT means a reset ? and we should just ignore this interrupt? 

What are the conditions this reset interrupt is triggered? 

Best Regards,

Anudeep Varada

  • 0
    TI__Guru* 76996 points

    Hi Anudeep,

    Anudeep Varada said:
    The value 0 of INT register means no pending interrupts correct? then why did the ISR was called? 

    Are you sending any CAN packets to get the interrupt?

    Can you please provide your project or simplest project with the issue, so that i can debug the issue at my end.

    --
    Thanks & regards,
    Jagadish.

  • 0 in reply to jagadish gundavarapu
    Prodigy 102 points

    Hi,

    yeah, I'm sending  the CAN messages. However the IE0 and IE1 bits were 0 so interrupt shouldn't be fired correct?

    I'm using the can file generated by the halcogen, with following change at the bootup after canInit()

        canREG2->CTL |= ~(1 << 1);
        canREG2->CTL |= ~(1 << 17);
    please find the can file in the attachement5074.can.c
  • 0 in reply to Anudeep Varada
    TI__Guru* 76996 points

    HI Anudeep,

    You are correct, if the IEx bits are zero then interrupts should not generate.

    And i verified old threads and errata as well and i don't see any issue related to this behavior.

    So, i want to test this behavior at my end. Give me some time to test and provide my updates.

    --
    Thanks & regards,
    Jagadish.

  • +1 in reply to jagadish gundavarapu
    TI__Guru* 76996 points

    Hi Anudeep,

    I understood the behavior, actually it is not an issue, and it is an expected behavior only:

    Actually, there were two interrupt enable bits in the CAN module side:

    1. Module level interrupt enable bit( IEx):

    It is module level interrupt enable bit and each CAN instance have one enable bit. For example, IE0 is the module level interrupt for CAN1

    2. Message object level interrupt:

    Each message object will have one interrupt.

    For example, you can enable message object-54 to interrupt by using below highlighted line in HALCoGen.

    So, as mentioned in datasheet the Intpend (Interrupt Pending) bit will get trigger on successful transmission or reception of messages if the message object level interrupts are enabled.

    I mean for example conisder, if we enable the message object level interrupt and disable the module level interrupt. Now if the corresponding message objects data transmitted / received then Intpend flag will get set. But OfCourse handler will get called because module level interrupt not yet enabled. And after some time if you enable the module level interrupt then handler will get called immediately because of the pending interrupts. And now handler should serve these interrupts. This is exactly the behavior that we are seeing in your side.

    Example:

    I am enabling the message object level receive interrupt for message object-54

    And i disabled the CAN module level interrupt, before sending the data to the message object-54

    So, if i send the message now, as you can see my interrupt handler not called but pending interrupts for corresponding message objects got set.

    So now if i enable the module level interrupt:

    Now you can see the interrupt handler got called immediately.

    If you don't want to set these pending interrupts, then we should not enable the message object level interrupts until we require.

    --
    Thanks & regards,
    Jagadish.