TMS320F2800155-Q1: LIN communication failure

Hi Delaney,

First of all, thank you very much for your reply，I will respond to your questions one by one.

1、We use LIN module.

2、It acts as a responder.

3、Using Tumos' LIN box。

4、Yes, when the SWnRESET bit is set, there will be data loss, and the error reported by the upper computer is not answered by the slave computer。My understanding is that when receiving data error, FE,PE are set, and then I set the SWnRESET bit, this time can not trigger the interrupt, resulting in no reply from the slave。

5、Yes, the phenomenon I see is that once PE,FE is set. rx,tx interrupt cannot trigger interrupt

6、The captured waveform is as follows。

That is all my replies to your questions,Looking forward to your reply.

Best Regards,

Zhang

Add the waveform of signal transmitted to mcu after processing by LIN chip module

Hi Zhang,

Which interrupt flags do you have enabled? The FE and PE flags of the LIN module should not block other interrupts from occurring. If using the LIN_INT_ID interrupt however, a misread header ID byte due to framing error could cause this interrupt not to get triggered. Are you using any other interrupts in your application (for example interrupts for different peripherals etc. that have a higher priority in the PIE and could be starving the LIN interrupt)?

From looking at your scope captures, the data shouldn't be causing framing errors since there appears to be a stop bit present for every received byte. Can you try sending data like 0xAA or 0x55 so that it is easier to differentiate between bits on the scope though?

Also note that performing a SWnRESET isn't the only way to clear the FE and PE flags. You could also do any of the following:

• Reading the corresponding interrupt offsets in the SCIINTVECT0/1 register
• RESET bit (SCIGCR0.0)
• System reset
• Reception of a new character (SCI-compatible mode) or frame (LIN mode)
• Writing a 1 to the FE and PE bits in SCIFLR

Best Regards,

Delaney

Hi Delaney,

Throughout the project, I used timer interrupts, PWM interrupts, and AD sampling interrupts. I think it's possible for you to say this, but what do I do, disable the global interrupt after entering the interrupt, and then turn on the global interrupt before the execution is complete? For the sent data, I have carefully read the waveform of each frame of data, and I can confirm that there is no problem with the waveform sent.

Best Regards,

Zhang

Hi Delaney,

Oh, and by the way, I used the LIN INT ID interrupt.

Best Regards,

Zhang

void LIN_init()
{
    LIN_initModule(LINA_BASE);
    LIN_enableInterrupt(LINA_BASE, LIN_INT_RX);
    LIN_enableInterrupt(LINA_BASE, LIN_INT_ID);
    LIN_setInterruptLevel0(LINA_BASE, LIN_INT_RX);
    LIN_setInterruptLevel1(LINA_BASE, LIN_INT_ID);

    Interrupt_register(INT_LINA_0, &level0ISR);
    Interrupt_register(INT_LINA_1, &level1ISR);

    Interrupt_enable(INT_LINA_0);
    Interrupt_enable(INT_LINA_1);

    LIN_enableGlobalInterrupt(LINA_BASE, LIN_INTERRUPT_LINE0);
    LIN_enableGlobalInterrupt(LINA_BASE, LIN_INTERRUPT_LINE1);
    LIN_clearGlobalInterruptStatus(LINA_BASE, LIN_INTERRUPT_LINE0);
    LIN_clearGlobalInterruptStatus(LINA_BASE, LIN_INTERRUPT_LINE1);
}
void LIN_initModule(uint32_t base)
{

    ASSERT(LIN_isBaseValid(base));
    EALLOW;
    LIN_disableModule(base);
    LIN_enableModule(base);
    LIN_enterSoftwareReset(base);
    LIN_disableSCIMode(base);
    LIN_setLINMode(base, LIN_MODE_LIN_RESPONDER);
    LIN_enableAutomaticBaudrate(base);
    LIN_setCommMode(base, LIN_COMM_LIN_USELENGTHVAL);
    LIN_setDebugSuspendMode(base, LIN_DEBUG_COMPLETE);
    LIN_setChecksumType(base, LIN_CHECKSUM_ENHANCED);
    LIN_setMessageFiltering(base, LIN_MSG_FILTER_IDRESPONDER);
    LIN_disableIntLoopback(base);
    LIN_enableMultibufferMode(base);
    LIN_enableParity(base);
    LIN_enableDataTransmitter(base);
    LIN_enableDataReceiver(base);
    LIN_triggerChecksumCompare(base);
    LIN_disableInterrupt(base, LIN_INT_ALL);
    LIN_setBaudRatePrescaler(base, 389U, 10U);
    LIN_setMaximumBaudRate(base, 120000000U);
    LIN_setFrameLength(base, 8U);
    LIN_setSyncFields(base, 0U, 1U);
    LIN_setTxMask(base, 0xFFU);
    LIN_setRxMask(base, 0xFFU);
    LIN_disableExtLoopback(base);
    LIN_exitSoftwareReset(base);
    EDIS;
}

#pragma CODE_SECTION(level0ISR, ".TI.ramfunc");
__interrupt void level0ISR(void)
{

    level0Count++;
    LinL2IntVect =LIN_getInterruptLine0Offset(LINA_BASE);
    LinId_test2 = LIN_getRxIdentifier(LINA_BASE);
    if((LinL2IntVect == 11)&&(LinId_test2 == 0xE2))
    {
       LIN_getData(LINA_BASE,LINReceive);
       LIN_User_Receive();
    }
    else if((LinL2IntVect == 11)&&(LinId_test2 == 0x64))
    {
        LIN_getData(LINA_BASE,LINReceive);
        can_rx_msg_rx_update = UPDATE;
    }

    LIN_clearInterruptStatus(LINA_BASE, LIN_INT_ALL);
    LIN_clearGlobalInterruptStatus(LINA_BASE, LIN_INTERRUPT_LINE0);
    Interrupt_clearACKGroup(INTERRUPT_ACK_GROUP6);
}

#pragma CODE_SECTION(level1ISR, ".TI.ramfunc");
__interrupt void level1ISR(void)
{
    level1Count++;
    LinL1IntVect = LIN_getInterruptLine1Offset(LINA_BASE);
    LinId_test1 = LIN_getRxIdentifier(LINA_BASE);
    if((LinL1IntVect == 4)&&(LinId_test1 == 0xE7))
    {
       LIN_User_Send();
       LIN_sendData(LINA_BASE,LINSend);
    }
    else if((LinL1IntVect == 4)&&(LinId_test1 == 0xA3))
    {
        //LIN_User_Send();
       // LIN_sendData(LINA_BASE,g_u16CanSendUpdate);
    }
    LIN_clearInterruptStatus(LINA_BASE, LIN_INT_ALL);
    LIN_clearGlobalInterruptStatus(LINA_BASE, LIN_INTERRUPT_LINE1);
    Interrupt_clearACKGroup(INTERRUPT_ACK_GROUP6);
}

Hi Delaney,

This is my LIN communication configuration, can you see what's wrong?

Best Regards,

Zhang

Hi Delaney,

In my project, I have a 100us timer interrupt, if I disable the timer interrupt, it seems that my LIN communication will not be interrupted, but if I enable the timer interrupt, it will cause my LIN communication to be interrupted, but it will not report any error, that is, there will not be any set in SCIFLR, just like normal communication. I also went to extend my timer interrupt, which caused my LIN communication to run longer before being disconnected, is there any way to increase the priority of my LIN communication interrupt? Or is there another way to deal with it? Look forward to your reply very much, thank you

Best Regards

Zhang

Hi Delaney ,

I also found a problem, it seems that the hardware circuit also interferes with me, I would like to ask what circumstances may interfere with my LIN communication.The specific phenomenon is that when I power on the high voltage end, the current is generated. At this time, the probability of triggering FE and PE will be much higher, and when I do not turn on high voltage and no current, there seems to be no error

Best Regards,

Zhang

Hi Zhang,

I would recommend looking at the interrupt_ex3_sw_prioritization example in the [C2000ware install]/driverlib/f280015x/examples/interrupt folder for more information about giving the LIN interrupt a higher priority. This is an example of preconfiguring the priority of the interrupts with software. I believe this will work for your use case.

What order are you wanting/expecting each of these interrupts to occur in for your application? For interrupt issues it is also generally useful to have each ISR output a high signal on a GPIO pin during execution so that you can identify when each ISR is getting called and compare this to the LIN data received at that time. This should allow you to see why LIN data is being lost or received incorrectly.

I will get back to you about your hardware question tomorrow.

Best Regards,

Delaney

Hi Zhang,

Noise on the LIN RX line could be the cause of framing and/or parity errors. The LIN RX line could be counting a logical 1 as a 0 or a logical 0 as a 1 and incorrectly detecting the data or getting invalid values for the LIN ID etc. In section 6.6 Electrical Characteristics of the datasheet, it specifies that an incoming signal is counted as logical high when it reaches 2.0V (VIH) and a logical low when it is below 0.8V (VIL). If you wanted to verify that the incoming signals are being counted as high/low correctly, you could measure the voltage of any noise spikes and make sure they are within the threshold. 

Best Regards,

Delaney

HI Delaney,

We have solved the problem, the source of the problem is still from the hardware interference, in this period of time, thank you very much for your reply, at the same time, I wish you more and more beautiful, happy every day.

Best Regards,

Zhang