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.

LAUNCHXL-F280039C: LIN showing Physical Bus Errors and Parity Errors (PBE & PE) but LIN_getData obtains right command

Part Number: LAUNCHXL-F280039C
Other Parts Discussed in Thread: C2000WARE

Tool/software:

Hello everyone,

I'm working on a prototype that requires LIN communication so given that I'll tell you my Hardware and Software setup:

Hardware:

  • LAUNCHXL-F280039C as a slave node with the following pins:
    • GPIO37 (LINTX)
    • GPIO33 (LINRX)
    • GPIO30 (WK)
    • GPIO47 (EN)
  • MIKROE-3816: Containing a TLE7259-3
  • Vector VN1630: As master node

Software: 

  • C2000Ware 4.01.00

My software implementation is pretty simple:

 #include "board.h"

 uint16_t rxData[8] = {0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF};

 void LinBase_Init(void)
 {
    LIN_initModule(LIN_VEHICLE_BASE);
    //
    // Enter Software Reset State
    //
    LIN_enterSoftwareReset(LIN_VEHICLE_BASE);
    LIN_setLINMode(LIN_VEHICLE_BASE, LIN_MODE_LIN_SLAVE);
    LIN_setCommMode(LIN_VEHICLE_BASE, LIN_COMM_LIN_USELENGTHVAL);
    LIN_setDebugSuspendMode(LIN_VEHICLE_BASE, LIN_DEBUG_COMPLETE);
    LIN_setChecksumType(LIN_VEHICLE_BASE, LIN_CHECKSUM_ENHANCED);
    LIN_setMessageFiltering(LIN_VEHICLE_BASE, LIN_MSG_FILTER_IDSLAVE);
    LIN_setBaudRatePrescaler(LIN_VEHICLE_BASE, 388U, 14U); //19236 bps
    LIN_setFrameLength(LIN_VEHICLE_BASE, 8U);
    LIN_setSyncFields(LIN_VEHICLE_BASE, 5U, 3U);
    LIN_setTxMask(LIN_VEHICLE_BASE, (uint16_t)(0xFFU));
    LIN_setRxMask(LIN_VEHICLE_BASE, (uint16_t)(0xFFU));
    LIN_enableParity(LIN_VEHICLE_BASE);
    LIN_enableMultibufferMode(LIN_VEHICLE_BASE);

    //
    // Finally exit SW reset and enter LIN ready state
    //
    LIN_exitSoftwareReset(LIN_VEHICLE_BASE);

    //Wake to LOW to assure WK pin on transiever on high
    GPIO_writePin(DIO_LIN_WK, 0);
    // EN to HIGH to assure the trainsiever is on NORMAL mode
    GPIO_writePin(DIO_LIN_EN, 1);
 }

//The cyclic task is being called every 100 us
 void LinBase_CyclicRx(void)
 {
    if(LIN_isRxMatch(LIN_VEHICLE_BASE))
    {
        /*
            Read the received data in the receive buffers then
            Clear the Interrupt status
        */
        LIN_getData(LIN_VEHICLE_BASE, rxData);
        LIN_clearInterruptStatus(LIN_VEHICLE_BASE, LIN_INT_ALL);
    }
 }

So you know from the transceiver is working properly since it is sending the LIN header and command to the TX pin, here some oscilloscope evidence:
 

With this configuration the C2000 can read the master request and dump it on the rxData array.

However, I see the following errors on the SCIFLR (PBE, NRE, PE are being set).

So here some thoughts:

1. As for right now the master is sending header and command properly

2. The configuration and the task is doing what is expected since it is obtaining the right LIN command.

3. According to the user manual:

  • PBE is an error that denotes that the there is short on the LIN line to VBAT or GND (but since we have the oscilloscope image we can see this is not happening)
  • NRE bit is set when there is no response to a Master's header completed within TFRAME_MAX, however this shouldn't be the case since in this message the Master is sending header and frames.
  • PE bit denotes a parity error, and in this case I have no clue how troubleshoot this, I double checked already the baudrate (is correct), I don't know if I need more configuration.

I would like to request your support in this matter, since I have already invested a few days trying to work out a simple example.

Thanks,

Martin

  • Hi Martin,

    Where exactly are you checking for these errors? Did you just add a breakpoint to the LIN RX ISR? My suspicion is that these flags could be getting raised due to the emulation and may not be actual errors (maybe the LIN state machine is getting thrown off somehow when the CPU is paused in the breakpoint).

    To check this, can you try enabling these interrupts on one of the LIN interrupt lines and seeing if they actually get branched to? Or you could add counters that get incremented in the ISR if the error flags are raised and turn on Continuous Refresh in the debugger to see if they get incremented. These methods would be a better indication of if these conditions are actually happening. 

    Best Regards,

    Delaney