CCS/TMS320F28377D: Time sequence of TxRqst and NewDat

Hi Ray,

Please see my comments below:

>>1. According to TRM chapter 22.11.3, it says that set the TxRqst with NewDat during transmission. The TxRqst is set right after the >>start of transmission with NewDat remaining set.
>>    The NewDat will be reset once the transmission is successfully finished. However, the end of chapter 22.11.4 says that when >>NewDat is set together with TxRqst, 
>>    NewDat will be reset as soon as the new transmission has started.  Why are they in totally different?

JC:  Section 22.11.3, NewDat will only remain set if DAR is disabled or there is a loss of arbitration/error

>>2. Since the chapter 22.11.3 and 4 say that the TxRqst and NewDat are both have the chance to be reset by CPU, however when I >>work my project on 28377D, 
>>    it seems that TxRqst and NewDat is never been reset anymore once I raised them. How is it happened? Is there anything >>configuration I did wrong?
>>    I am sure that the SINGLE CAN packet is successfully transferred by CAN king. 
>>    And I just let CPU process to stuck in an infinite while loop for a short time before I pause the debug to observe the register >>status.

JC:  To confirm that transmission of the packet by F28377D CAN did take place, is there a node that is able to receive the packet.  Your screen capture shows that the F28377D CAN transmitted 4 bytes with a value of 0x0C100040.  Just curious to see if this packet ever made it to the CAN bus so a receiving node can confirm it if it has the same CAN data.  I'm assuming this is what CAN king received?  

>>3. According to TRM chapter 22.11.5, to achieve the continuous transmission, TxRqst can be set with NewDat. 
>>    Then we can directly update the data register without the reset of TxRqst or MsgVal. 
>>    However, this method has a shortage that the packet failed to transfer cannot be re-exported. I did an short experiment and find >>out it is true.
>>    Is there anything method to realize the continuous transmission without this side effect?

JC: Not sure if there is another alternative to continuous transmission.  My question here though is that in your application, is preventing the reset of TxRqst going to break something, or is resetting and setting of TxRqst critical in throughput that this has to be avoided?

Best regards,

Joseph

Hello Joseph,

Thanks for your reply. Here is my response.

>> 1.
JC:  Section 22.11.3, NewDat will only remain set if DAR is disabled or there is a loss of arbitration/error

RT: I got it! That is clear. Can' t believe I just ignore that.

>> 2.
JC:  To confirm that transmission of the packet by F28377D CAN did take place, is there a node that is able to receive the packet.  Your screen capture shows that the F28377D CAN transmitted 4 bytes with a value of 0x0C100040.  Just curious to see if this packet ever made it to the CAN bus so a receiving node can confirm it if it has the same CAN data.  I'm assuming this is what CAN king received?  

RT: Well, I should stretch the register window to let you see the IF1DATB. But I can promise that the data recognized by CAN king is correct. You can see the figure as follow. At least the IF1DATA is correctly displayed on the CAN king output window.
(Since IF1DATA is 0x0C100040.)

3.
JC: Not sure if there is another alternative to continuous transmission.  My question here though is that in your application, is preventing the reset of TxRqst going to break something, or is resetting and setting of TxRqst critical in throughput that this has to be avoided?

RT: I am not understood what you said about the break of something caused by the reset of TxRqst or how the state of TxRqst is going to influences the throughput. However, my final goal is to find a way to ensure the CAN packet is successfully finished. Since the busy bit in IFxCMD is set after CPU sets the TxRqst bit in IFxMCTL but soon being reset after all the data is sent to shift register. Therefore, the busy bit is unusable for me. This result will be displayed as the following figure.

The debug pin represents the detection of busy bit. It will be high if the busy bit is set.

The reason I need something to make sure the finished transmission of CAN packet is that if I set TxRqst ONLY during the back-to-back continuous transmission, the second packet will be failed to transfer. However, to set TxRqst with NewDat is unreliable since that once a packet is failed to transfer, the CAN core will not resent it anymore. There exist some risk of packet lost.

So here is my fourth question:
4. Is there any register bit can represent the end of transmission? Take USART communication on STM for example, there has a TC (transmission complete) bit which will be set after the end of each successful transmission. TC bit is set automatically by hardware of MCU and can be reset by firmware. The time diagram is show as follow:

Thanks for TC bit, the timing of the end of transmission is clear for user. Is there any similar bit for CAN on TI?

Thank you so much.

Best regard,
Ray Tsai.

Hi Ray,

Thank you for providing the snapshots.  These help a lot with the explanations.  Did you get a chance to poll the CAN_ES and CAN_ERRC registers in the CCS register window after transmission?  Maybe they will indicate something related to item# 2 as to why TxRqst and NewDat are never reset although it shows in your CAN king results that data transmitted correctly. 

In the meantime, I'll investigate further on your questions and will get back with you as soon as I have answers.

Regards,

Joseph

Hi Joseph,

Here is the CAN_ES and CAN_ERRC registers snapshots. Does it help?

By the way, I read the TRM again and found out there is an IntPnd bit will be set after a packet has been transferred successfully if the TxIE in CAN_IFxMCTL is set. Although I do not enable the interrupts, I am not sure that if there is no risk by using it. Would you please help me to confirm it?

Thank you.

Best regard,
Ray. Tsai.

Hi Joseph,

I am sorry for replying you late.

Actually I found that the TxRqst bit in CAN_TXRQ_21 and NewDat bit in CAN_NDAT_21 dose set and reset as the TRM mentioned.
So I don't need IntPnd bit anymore. And all my question is solved.

Thank you for a series of help. Really appreciate it.

Best regard, Ray. Tsai.