Other Parts Discussed in Thread: TMS320F2812
We need help understanding an errata for the TMS320F2812 eCAN, published in the SPRZ193L document.
The published errata states, “If the CPU reads the LAM/MOTO/MOTS register area at the same time that the eCAN controller is accessing (reading or writing) the eCAN mailbox RAM area (MSGID, MSGCTRL, MDL, or MDH registers), the CPU may erroneously read all zeros (0x00000000).”
The published workaround states, “For all CPU reads from the LAM/MOTO/MOTS register area, check to see if the read returns all zeros. If so, the CPU should perform a second read. If the second read returns zero as well, then the data is correctly zero. If the second read returns a non-zero value, then the second data is the correct value. Note that interrupts must be disabled during the consecutive CPU reads.”
The problem that we observe occurs when our program reads the Message Object Time Stamp (MOTS) from the eCAN mailbox RAM area while the eCAN hardware is simultaneously accessing the eCAN mailbox RAM area.
We are using 15 mailboxes (mailbox 15 through mailbox 1) to receive messages with the same Message Id (MSGID).
Here is a snippet of our code that executes with interrupts disabled:
TimeStamp1 = ECanaRegs.MOTSs.MOTS15 | ECanaRegs.MOTSs.MOTS15;
We assumed that the above snippet of code satisfied the published workaround. However, we found that under certain circumstances, the above snippet of code does not seem to resolve the errata. We observed, that under certain circumstances when apparently the eCAN hardware is simultaneously accessing the eCAN mailbox RAM, that the above code produces an incorrect value for TimeStamp1.
Here is another snippet of code (executing with interrupts disabled) with additional debugging information:
eCanShadow.CANRMP.all = ECanaRegs.CANRMP.all & 0x0000FFFE; /* RMP15 to RMP1 */
if (eCanaShadow.CANRMP.bit.RMP15 != 0)
{
TimeStamp1 = ECanaRegs.MOTSs.MOTS15 | ECanaRegs.MOTSs.MOTS15;
TimeStamp2 = ECanaRegs.MOTSs.MOTS15 | ECanaRegs.MOTSs.MOTS15;
if (TimeStamp1 != TimeStamp2)
{
asm(" ESTOP0"); /* This should not occur. */
}
}
If the above code (that is accessing mailbox 15) executes while the eCAN hardware is simultaneously accessing the eCAN mailbox 14, then we have found that sometimes TimeStamp1 is not equal to TimeStamp2.
We need a better, in depth understanding of the eCAN hardware errata. Let’s look closer at our workaround:
TimeStamp1 = ECanaRegs.MOTSs.MOTS15 | ECanaRegs.MOTSs.MOTS15;
The assembly code for the above line of code shows we are reading the MOTS register in two successive assembly instructions, back-to-back. Perhaps there needs to be more time in between the two successive reads? Maybe BOTH reads are in conflict with the eCAN hardware?
If we put a small delay between the two successive reads of the MOTS register, then everything seems to work.
It seems that there are some undocumented requirements in regard to the workaround. Is there a MINIMUM amount of time between two successive MOTS reads that must be satisfied, and is there a MAXIMUM amount of time between two successive MOTS reads that must be satisfied?
The workaround published in errata SPRZ193L recommends the following:
TimeStamp1 = ECanaRegs.MOTSs.MOTS15;
if (TempStamp1 == 0)
{
TimeStamp1 = ECanaRegs.MOTSs.MOTS15;
}
The above snippet of code seems to work; i.e. we observe no problems. But the above snippet of code is functionally no different than the following line of code that we are using, except for the different amount of delay between the two reads of the MOTS.
TimeStamp1 = ECanaRegs.MOTSs.MOTS15 | ECanaRegs.MOTSs.MOTS15;
Can someone provide more detailed information on this errata?
Eric