TMS320F280049C: LIN stack development: Reception of an incomplete header

Barbara,

Thanks for reaching out to us via the E2E forumn.  The C2000 LIN expert is out today, but will be back in the office tomm and give an initial reply at that time.

Best,
Matthew

Hi Barbara,

I am not sure what you mean by "As you can see from the timestamps the pause between the incomplete header and the next complete one is already relatively long, so that the module could recover, but it does not"

Based on the second snapshot it looks like the PERR goes low as soon as you give SYNC Break field to the next complete header, so I dont understand what you mean by module is not responding?

Since you have enabled Parity Error Interrupt, due to incomplete frame it should generate interrupt, are you saying that interrupt does not occur?

Regards,

Nirav

Dear Nirav!

Sorry, I expressed myself not correctly. With above sentence I meant that the module did not respond on LIN because I didn’t get an ID interrupt for the correct LIN header received. I get only the Parity Error. And this is what is causing me currently the problems. I would expect that the LIN module is at some point recovering from the incomplete header (by timeout for example) and will be ready for a new header within a certain time. But it seems that it waits for the PID field for indefinite time and cannot respond to the next complete header. This is failing the LIN compliance (LIN 2.2) however.

I’m looking for a method where I can activate a timeout in the LIN module when a header is started or if there is any information from the LIN module where I can see if the module is currently busy so that I can implement a timeout myself and reset the module if the PID field is not being received.

Kind regards,

Barbara

Hi Barbara,

You should get an interrupt due to Parity Error on incomplete header, which you should be able to clear by writing into SCICLEARINT.CLRPEINT and SCIFLR.PE in  your interrupt ISR. Once you do that on the next complete header you should get ID complete interrupt.

I am not clear from your explanation on how are you handling Parity Interrupt on incomplete header? If you are expecting LIN to recover by itself that is not going to happen, as you will need to service and clear the interrupt before the next packet comes.

Please try clear the Parity interrupt and let me know if you are still seeing the issue.

Regards,

Nirav

Dear Nirav!

This is the main problem: I don't get the parity interrupt for the incomplete header. It comes when the next header is started.

I'll refer to my first post now, I made 2 screenshots. The first one shows the incomplete header - there is no interrupt. The second screenshots shows the following 2 complete headers. In the first complete header I receive the Parity Interrupt. I serve this interrupt, but the header is NOT recognized as a complete header. The third header which is also complete works fine again. 

I clear all interrupt flags when serving interrupts:

intVector = LIN_get_irq();

LinaRegs.SCIFLR.all = 0xFFFFFFFFu;

My current problem is still: I don't get any interrupt during or after the incomplete header (the incomplete header consists only of Sync Break and Sync Field):

The IRQ line should toggle once for an interrupt, but it doesn't. The trigger line is an external signal for my logic analyzer. I only get an interrupt when the next header comes. And then the LIN module does not recognize the complete header only the parity error. For your information: As soon as I add an start bit after the sync field the Parity Interrupt is coming, but this is not what the test requires.

Is there any information available in the LIN module that it is busy with receiving a header?

Kind regards, Barbara

Hi Barbara,

Did you enable interrupt for Inconsistent-Sync-Field-Error? You may need to do that for the Interrupt to be generated. Please try configuring below registers, and let me know if you get the interrupt or not.

SCICLEARINT.CLRISFEINT = 0x1;

SCISETINT.SETISFEINT = 0x1;

SCISETINTLVL.SETISFEINTLVL = 0x1;

Regards,

Nirav

Dear Nirav!

I do now following in my init function:

/* Set all interrupts to disabled */
LinaRegs.SCICLEARINT.all = 0xFFFFFFFFu;

/* set the enable interrupts register */
LinaRegs.SCISETINT.bit.SETBRKDTINT = 0u; /* (SCI compatible mode only) */
LinaRegs.SCISETINT.bit.SETTXINT = 0u; /* not used, use RX INT for checking own TX message */
LinaRegs.SCISETINT.bit.SETRXINT = 1u; /* response received */
LinaRegs.SCISETINT.bit.SETIDINT = 1u; /* ID (header) received */

LinaRegs.SCISETINT.bit.SETPEINT = 1u; /* parity error */
LinaRegs.SCISETINT.bit.SETOEINT = 1u; /* overrun error */
LinaRegs.SCISETINT.bit.SETFEINT = 1u; /* framing error */
LinaRegs.SCISETINT.bit.SETNREINT = 1u; /* no-response error */
LinaRegs.SCISETINT.bit.SETISFEINT= 1u; /* inconsistent-synch-field error */
LinaRegs.SCISETINT.bit.SETCEINT = 1u; /* checksum error */
LinaRegs.SCISETINT.bit.SETPBEINT = 0u; /* physical bus error detection only by master */
LinaRegs.SCISETINT.bit.SETBEINT = 1u; /* bit error */

LinaRegs.SCISETINTLVL.bit.SETISFEINTLVL = 1u;

/* Release SCI from software reset state - End of Config */
LinaRegs.SCIGCR1.bit.SWnRST = 1u;

Previously the line with SCISETINTLVL was missing, but all other interrupts seem to work fine. Is there a reason why this may need a different level?

I am still getting no interrupt for a valid sync break + sync field combination. However I did some additional tests. I have no problem if the sync field is incorrect (all values except 0x55 tested). I get there no interrupt either, but the LIN module recognizes the next header correctly. 

The only problem is still if the sync field is also correct and no PID field is sent. But since I don't get any ISF IRQ (even if the sync field is not correct), I will check why this does not occur. 

Regards,
Barbara

Hi Barbara,

It looks like once the sync field is sent correctly it does not generate ISF interrupt, and after that it waits for the valid Frame. Let me check with our design team if their is a time out in-built. I will get back to you in couple of days.

In the meantime, have you tried porting the LIN stack developed for other TI devices like TMS470 etc. to see if it is giving you the same problem or not?

Regards,

Nirav

Dear Nirav!

Ok. Is there any way that I can detect if the LIN module is busy during the header reception? I could implement a software timeout then. 

We have done in the past LIN stacks for a TMS320F28035 and CC2640. The TMS320 already had the same problem. I am not sure why that was accepted at that time. There was no such failure mentioned for the one for CC2640.

For your information: I work for a small software house that is specialized on communication stacks such as LIN for automotive applications. This means that we work after our customer’s requirements – which is the TMS320F280049. Trying a different µC is unfortunately not covered by our budget for the project. And I don’t think that my customer wants to change his complete HW design.

Kind regards,

Barbara

Hi Barbara,

Thanks for the information. Understood!!

Looking more into design, it appears that TIMEOUT in-built is at least 4 seconds for LIN to give an interrupt (TIMEOUT interrupt). Can you wait for 5seconds after you send the incomplete header (with sync break and sync field) before you send the next complete header and see if it generates TIMEOUT interrupt or not?

Also, can you dump all the LIN registers after 5seconds of incomplete header received?

Thanks & Regards,

Nirav

Dear Nirav!

I saw this timeout also in the reference manual. It is used as bus idle timeout. It works as expected. 4 seconds after last edge on LIN the timeout comes. However, it does not influence the state of header reception, I still get parity error for the following complete header:

Cursor A shows the bus idle timeout after the incomplete header. The following header still generates PERR. 

Here the dump of the LINAREGs:

521177 40
R LinaRegs_SCIGCR0 0x0000000B 0x00000001
R LinaRegs_SCIGCR1 0x0000000B 0x1EC40000
R LinaRegs_SCIGCR2 0x0000000B 0x03001EC4
R LinaRegs_SCISETINT 0x0000000B 0x00000300
R LinaRegs_SCICLEARINT 0x0000000B 0x00020000
R LinaRegs_SCISETINTLVL 0x0000000B 0x22100002
R LinaRegs_SCICLEARINTLVL 0x0000000B 0xBF002210
R LinaRegs_SCIFLR 0x0000000B 0x2210BF00
R LinaRegs_SCIINTVECT0 0x0000000B 0xBF002210
R LinaRegs_SCIINTVECT1 0x0000000B 0x0000BF00
R LinaRegs_SCIFORMAT 0x0000000B 0x10000000
R LinaRegs_BRSR 0x0000000B 0x00001000
R LinaRegs_SCIED 0x0000000B 0x10000000
R LinaRegs_SCIRD 0x0000000B 0x09081000
R LinaRegs_SCITD 0x0000000B 0x00000908
R LinaRegs_SCIPIO0 0x0000000B 0x00000000
R LinaRegs_SCIPIO2 0x0000000B 0x00000000
R LinaRegs_LINCOMP 0x0000000B 0x00000000
R LinaRegs_LINRD0 0x0000000B 0x00000000
R LinaRegs_LINRD1 0x0000000B 0x00000000
R LinaRegs_LINMASK 0x0000000B 0x00000000
R LinaRegs_LINID 0x0000000B 0x00000000
R LinaRegs_LINTD0 0x0000000B 0x00060000
R LinaRegs_LINTD1 0x0000000B 0x00000006
R LinaRegs_MBRSR 0x0000000B 0x00000000
R LinaRegs_IODFTCTRL 0x0000000B 0x00000000
R LinaRegs_LIN_GLB_INT_EN 0x0000000B 0x00E20000
R LinaRegs_LIN_GLB_INT_FLG 0x0000000B 0xFFFF00E2
R LinaRegs_LIN_GLB_INT_CLR 0x0000000B 0xFFFEFFFF

Again the question: Is there any way to detect in the LINAREGS if the module is currently busy? Or should I not spend any more time in this and try to figure out how to do this in SCI mode?

Kind regards, Barbara

Hi Barbara,

Once you get a TIMEOUT error/interrupt you will have to assert SWnRST (SCIGCR2.SWnRST=1) this will reset the LIN and when you get the next complete header you will not get any Parity Error/Interrupt.

Unfortunately their is no indication from LIN that it is busy until you give START bit. So when you have header that has Sync break and sync field ONLY, you will have to rely on TIMEOUT interrupt, and if the next header comes before 4s then you will have similar condition (where it gives Parity ERROR).

One question though, the register dump that you provided is it before the Timeout, after the Timeout or after next complete header?

Is it possible for you to generate register dump right after incomplete header (Sync break and sync field)?

I think you will run into similar issue even in SCI mode.

Regards,

Nirav

Hi Barbara,

Do you need any further assistance on this issue? Let me know if you have any more information and need help from my side.

Thanks & Regards,

Nirav

Dear Nirav!

Sorry for the late response - I was only in office on Thursday until noon and Friday was a public holiday. 

The register dump was about 5 seconds after the incomplete header (as requested by you in the post before the dump - so it was after the timeout but before the next header - I changed the testrun accordingly). 

Using the timeout that is intended to recognize the bus idle timeout for LIN is not feasible. 4 seconds after the last edge on LIN the device is expected to go to sleep (and not to reset UART and try to communicate now fault free). The problem is that the node is a LIN slave - we are utterly dependent on the LIN master about communciation schedule.

I will try to generate the new register dump today, but I have a bit much work to do right now. But I'll do the dump tomorrow latest. 

Thank you for your help and ideas so far. 

Kind regards,Barbara

Dear Nirav!

I did today the dump of the LINAREGs after Incomplete header before Timeout:

521177 40
R LinaRegs_SCIGCR0 0x0000000B 0x00000001
R LinaRegs_SCIGCR1 0x0000000B 0x1EC40000
R LinaRegs_SCIGCR2 0x0000000B 0x03001EC4
R LinaRegs_SCISETINT 0x0000000B 0x00000300
R LinaRegs_SCICLEARINT 0x0000000B 0x00020000
R LinaRegs_SCISETINTLVL 0x0000000B 0x22100002
R LinaRegs_SCICLEARINTLVL 0x0000000B 0xBF002210
R LinaRegs_SCIFLR 0x0000000B 0x2210BF00
R LinaRegs_SCIINTVECT0 0x0000000B 0xBF002210
R LinaRegs_SCIINTVECT1 0x0000000B 0x0000BF00
R LinaRegs_SCIFORMAT 0x0000000B 0x10000000
R LinaRegs_BRSR 0x0000000B 0x00001000
R LinaRegs_SCIED 0x0000000B 0x10000000
R LinaRegs_SCIRD 0x0000000B 0x09081000
R LinaRegs_SCITD 0x0000000B 0x00000908
R LinaRegs_SCIPIO0 0x0000000B 0x00000000
R LinaRegs_SCIPIO2 0x0000000B 0x00000000
R LinaRegs_LINCOMP 0x0000000B 0x00000000
R LinaRegs_LINRD0 0x0000000B 0x00000000
R LinaRegs_LINRD1 0x0000000B 0x00000000
R LinaRegs_LINMASK 0x0000000B 0x00000000
R LinaRegs_LINID 0x0000000B 0x00000000
R LinaRegs_LINTD0 0x0000000B 0x00060000
R LinaRegs_LINTD1 0x0000000B 0x00000006
R LinaRegs_MBRSR 0x0000000B 0x00000000
R LinaRegs_IODFTCTRL 0x0000000B 0x00000000
R LinaRegs_LIN_GLB_INT_EN 0x0000000B 0x00E20000
R LinaRegs_LIN_GLB_INT_FLG 0x0000000B 0xFFFF00E2
R LinaRegs_LIN_GLB_INT_CLR 0x0000000B 0xFFFEFFFF

There seems to be no difference. 

If you have any further ideas how I might get an earlier recovery I would appreciate it. But I will inform my customer that it currently seems that there is no way to prevent this fail. 

Kind regards, Barbara

Hi Barbara,

I looked at the register dump, and I am not sure why there are so many flags being set.

LinaRegs_SCIFLR 0x0000000B 0x2210BF00 - CE=1, OE=1, IDTXFLAG=1, RXWAKE=1, TXEMPTY=1, TXWAKE=1, RXRDY=1, TXRDY=1,

Were these flags cleared before incomplete header was received?

Can you also dump the LIN registers before the incomplete header is received? So that we have an idea on which flags got set after the incomplete header was received.

Regards,

Nirav 

Hi Barbara,

In the meantime let me confirm one more time, if there are no other flags or indication from LIN to detect this fail scenario before you communicate to your customer. I will get back to you latest in couple of days.

Regards,

Nirav