LIN communications in TMS570LC4357

My goal is that, the labview GUI send the board with data thru LIN. Board is configured as slave. Once the board receives the data, it sends back to labview GUI.

But it didn't work.

But, after I tried the code at https://e2e.ti.com/support/microcontrollers/hercules/f/312/p/180455/650524#650524.

And set my board as master and use loopbackmode (analog loopback), from the scope,  I can see signasl at TX and RX and LIN output at the drive chip.
I set it as polling only, didn't set it as DMA or INTERRUPT mode.

However, the labview bus monitor still sees nothing and complains about the frame error.


If I configure the board as non-loopback, I can't see my send signal from scope at all.


Can anyone give me some ideas?


Thanks a lot!


PS: here is the code:


linSetFunctional(linREG1, 0x00000006);

linREG1->IODFTCTRL = 0x00000A02;

linSetLength(linREG1,8);


linSend(linREG1, TX_data);

linSendHeader(linREG1, 0x1);

if(linIsRxReady(linREG1))
        {
            linGetData(linREG1, RX_data);
        }

LIN is different than a UART - it's some automotive protocol.

We have one peripheral that is SCI/LIN but in HalCoGen it appears twice. There is a driver for SCI (UART) and a different driver for LIN.

If you want to use this peripheral to act as a UART and send data back to the PC then you should configure it as a SCI and use the SCI drivers from HalCoGen. It appears you are using the LIN driver instead.

-Anthony

My questions are

1) My setup is like this: I used the LIN driver and set the loopback mode in the register of IODFTCTRL == 0x00000A02. I used the scope to probe the TX and RX,both channels have data. It shows data transmitted and received. However, if I used a LIN bus monitor from labview to monitor LIN bus, it shows no data. I don't know why?

2) Our labview GUI is sending out LIN data. If I used another labview setup at the receiving end, it can receive the data and of course, the labview LIN bus monitor can see the signals on the bus. If I replaced the labview setup at the receiving end with my board, I could not receive any data. As you described, do you mean that I should change to SCI driver in order to receive LIN data in my board at the moment? 

3) If I disabled the loopback mode and used the LIN driver to send out data from board, I could not see any data on TX with scope probe. i don't know why.....

could you please give me more ideas?

Thanks

Yue,

So to be clear then, you have something like:
sine.ni.com/.../203383

And you are using this to connect to the device. The GUI in LabView is talking to the LabView LIN bus monitor like above.
You are not trying to read data through the UART on the board you are using.
(Are you using a TI HDK or LaunchPad?)

Ok so if you actually have a LIN bus monitor then the first question is did you add a LIN transceiver to the development kit? Our development kits do not include a transceiver...

Hi Anthony,

Here is the NI tools we used:

http://sine.ni.com/nips/cds/view/p/lang/en/nid/210075

The board is our homemade board with LIN transceiver on it. With loopback setup, we can see the data from the scope at the TX, Rx and LIN pin from the transceiver but the NI'labview LIN bus monitor can't see anything.

So, my questions are

1) Once we have LIN data on TX or RX, the bus monitor should be able to see it, right?

2) If not, is there any possibility that some register settings were wrong in my code?

Thanks a  lot!

Hi Yue,

Ok thanks.  Right now the exact tool isn't important but knowing you have a protocol analyzer in the picture really clears things up.

To be honest I know very little about LIN but ...

1) Once we have LIN data on TX or RX, the bus monitor should be able to see it, right?

I don't think so.  If you probe the TX and RX lines at the transceiver these are what go to the microcontroller.

The signal that goes to the NI tool is also important.

If you look at the HDK's LIN add-on board

  you will see

If you just probe the Green points (LINRXD, LINTXD) there could still be a problem on the RED point which is the actual bus.

So please check the RED point int he diagram above (or it's equivalent for your adapter board).

2) If not, is there any possibility that some register settings were wrong in my code?

If the signal there is good - then it could still be an issue of timing mismatch between how the MCU is configured and how the LIN protocol analyzer is configured.  I think like a UART there is a baud rate that needs to be set.

But first, let's see what the signal looks like on the RED and make sure it's valid.

If you need help with that please upload an oscilloscope shot of this node so we can analyze.

BTW, I connected the PCAN-USB pro and use the PLIN-VIEW pro to monitor the bus. I got nothing. I am curious whether I should NOT use the loopback mode. ??

If you mean one of the TMS570's internal loopback modes - I would turn these off.
They are normally used for IO self-testing and tend to disconnect the pins from the bus...

Anthony,

I will check the points you mentioned.

As for loopback, in LIN portion of TMS570, there is register of SCIGCR1 and IODFTCTRL for the loopback mode setting. It is for LIN self-test. At this moment, there is data on the LIN bus but these data can't be monitored by PLIN-VIEW?

Thanks

So IODFTCTRL has 0x00000500 and SCIGCR1 bit 16 = 0? If so that's good.

Is the PLIN-VIEW a different LIN bus analyzer (hardware) tool that you have? Can the Labview LIN analyzer and the PLIN analyzer talk to each other?

That is correct.

And,my LIN transceiver peripheral is same as you show. Now, I can see both data at two GREEN and RED points.

Labview can talk to my PLIN-VIEW with out issue (Labview sender is master and PLIN-VIEW is slave). It means Laview and PLIN-VIEW settings are correct

My baud rate setting in Halcogen is as follows:

linREG1->BRS = (uint32)243U;

 linREG1->MBRSR = (uint32)3514U;

Hi Anthony,

Yes, the registers' values are as what you described.

The PLIN-VIEW is a software associated with PCAN-USB prob dongle (from PEAK company) to monitor LIN bus. Right now, if the labview device is set as master and PLIN-VIEW is set as slave, they can talk without issue.

PLIN-VIEW can't receive my board's data.

Right now, I took out loopback mode, still I could see the data from scope at the GREEN points (TX and RX) and Red point (LIN). More confused....

Anthony,

I put my LIN code into a task which loops every 50us. My LIN com's baud rate is 19.2kHz.

My code is
while(1) //loop every 50us
{
if(linIsTxReady(linREG1))
{
linSendHeader(linREG1, 0x1);
linSend(linREG1, TX_data);
}


if(linIsRxReady(linREG1))
{
linGetData(linREG1, RX_data);
linREG1->FLR |=0x000000200;
testID = linREG1->ID &0x000000FF;
}
}

But, I found my TXRDY never turns TRUE.

I put this code into another task which loops every 1ms. Now, my TXRDY can turn TRUE.... Why?

BTW, I check the succesful LIN com between labview gui and LIN com box (PLIN-VIEW). I found labview gui is sending out the data much faster (observed from scope) than from my board although having the same baud rate setting. I am confused about this part.

I didn't use any interrupt or DMA mode but polling this TXRDY or RXRDY only.

Please give some ideas

Thanks!

Yue Li2 said:

I put this code into another task which loops every 1ms. Now, my TXRDY can turn TRUE.... Why?

Can't really tell from this information.   If you are using an RTOS with different tasks the first thing I would do is to check whether the tasks have the same properties..   do they both have access to the LIN module or have you set the MPU differently?  Does one run in privilege mode while the other doesn't?   Are they really both running w. the same scheduling?   Is one task activated in an interrupt routine for LIN (by some OS construct) while the other isn't?

Yue Li2 said:

I check the succesful LIN com between labview gui and LIN com box (PLIN-VIEW). I found labview gui is sending out the data much faster (observed from scope) than from my board although having the same baud rate setting. I am confused about this part.

So start from the basics.   Check your clock input frequency v.s. what you have programmed into HalCoGen.

Then turn on a clock output to make sure you're really running at the PLL frequency you think you are.   For example, if the PLL is not enabled, or if there was an error and your chip switched from the oscillator to one of the internal ring oscillators - then you may be not running at the frequency that you think you are.    Since the LIN baud rate is divided down from one of the VCLKs which is usually the PLL, an error here could throw the baud rate off.

Hi Anthony,

Thanks a lot for your reply!

I am not using a RTOS but state machines. there are two tasks one is looping at 10us the other is at 1ms. the second task runs depending on the first task. It is like two while loops looping at different rate. Other than LIN, there are CAN, PWM and other fucntions which are running well.

I didn't use the interrupt or DMA in the LIN communications, but polling the TXRDY bit always. Once it is set, there is linSend(tx_data). But, I found that such TXRDY bit can never set when I put it in the "10us loop", but can set and tranmist data in the "1ms loop" where such data can be observed from scope but never received by any third party LIN bus monitor device such as www.peak-system.com/PCAN-USB-Pro-FD.366.0.html

That is why I confused.

I have made sure that my PLL and my LIN baud rate settings from Halcogen are correct.

Ok so the difference is that the one loop runs every 10us and the other every 1ms? That sounds reasonable.
Like it takes longer than 10us for a message to be sent.

I think you still need to output a clock on a pin like ECLK and confirm that you are actually *running* off the PLL.

For example on one board we have here (the CNCD) someone put an 'osc kill' pushbutton on the back of the board.
It is very easy to accidentally press this button and that causes the external oscillator to fail. The device will switch over to run off the internal low power oscillator at a much lower frequency than expected. Most of our launchpads have a jumper on them to do the same.

Something like this could be causing you to not actually run at the frequency you think you are running just from HalCoGen.

But if you turn on a pin like ECLK and measure the output frequency of one of the internal VCLKs you'll know for sure whether there is a clocking problem or not.

Anthony,

I don't think it is a clk issue otherwise my PWM and CAN should be all wrong, but they are working fine. So, I am thinking whehter I have to use interrrupt to make LIN works just like CAN does in my code.

Thanks

Ok but you said the baud rate on the LIN bus from the MCU is wrong (slower) than what the other two devices are configured for, correct?

So if you think the clock is correct, then the next step is to calculate the baud rate by hand to make sure it's not a bug in HalCoGen's calculation [it has been known to have calculation errors].

For ECLK you need to turn it on,  see 6.6.4 Clock Test Mode in the datasheet SPNS195C and 2.4.4 Clock Test Mode in the TRM SPNU563.

HI Anthony,

No, I probably didn't explain it clearly.

I found the data transmitted out on the scope but "slower". Then I found because I put it my "1ms loop". Yes, data can be transmitted out but at very low freq. Maybe that is the reason that my LIN monitor device can not see the data(?) Then, I used labivew to transmit same data (break+sync+ID+data) at the same baud rate setting. I can see the same data but they are coming out at much faster rate. But the LIN bus monitor can receive such data from labview.

Okay, then I put my LIN code in "10us loop", and polling the TXRDY bit which never turns true, that means there is no data transmitted out! Confused...why? do I need to use interrupt?


I manually calculated the baud rate. It is 19.2kHz. It is same as the setting in Halcogen.

My code:

   if(linIsTxReady(linREG1))
    {
        linSendHeader(linREG1, 0x1);
        linSend(linREG1, TX_data);
    }

     if(linIsRxReady(linREG1))
     {
        linGetData(linREG1, RX_data);
        linREG1->FLR |=0x000000200;
        testID = linREG1->ID &0x000000FF;
     }

Hi Anthony,

There is some update from what I did last night.

I set LIN bus in interrupt mode when receiving data on the bus. I used labview to send the LIN data which was proved to be good data since it could be monitored by another LIN bus monitor device. However, DSP still could not see the data and of course it didn't go to interrupt at all.

I checked the RX pin where I could clearly see the data coming into the DSP. I attached a register map snapshot for your reference.

That didn't make sense to me. I summarized what I did:

1) I set the LIN bus in loopback mode and put the code in my "1ms loop", it can send and receive data. Such data can be seen from scope but LIN bus monitor can NOT see it.

2) Then, I put the code into my "10us loop", then TXRDY bit never turns TRUE. Unless I don't use "if(TXRDY)" but sending out data directly, I could not send out data. I took out the loopback mode, it still could not send out data.

3) Then, I used interrupt mode like SET RX INT. However, my code never goes to interrupt since it is like the DSP could not see the data on the RX pin.

4) I checked the EXCLK pin, it works fine with correct clock signals.

5) I manually recalculated the baud rate. It is correct.

Stuck here.....and checking the code again.