LAUNCHXL2-TMS57012: CAN library, Receiving CAN packet, stuck on NWDATx

To clarify, NWDATx[regIndex], where regIndex = 0 in this case and bitIndex = 1, remains 0. Even when it seems like the microcontroller is acknowledging the received message when examining the oscilloscope signals in TX, NWDATx[regIndex] is 0, and thus stays in the while loop.

Hi Tomas,

First make sure whether you are using extended or standard ID in the CAN instance.

If you are using extended ID then make sure to enable the same setting in your USB to CAN analyzer also.

(+) TMS570LC4357: DCAN Receive not working - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

If we didn't enable it then we might not receive the packets properly.

--
Thanks & regards,
Jagadish.

The issue still persists. However, with the extended CAN instance, the CAN bus does work on a new project I made from scratch that just has CAN1 enabled through HalCoGen. I coded the new project to be as close as possible to just requesting and receiving data from CAN the same way the 6.3 Hercule Bootloader Example project does.

However, for the 6.3 Hercule Bootloader Project Example, it still appears that it is stuck on that line. Can you give any other suggestions?

I've narrowed it down to what seems like the initialization in bl_dcan.c for the Example Project with the function CANMessageSetRx.

Hi Tomas,

Did you refer the below application notes of CAN bootloader:

CAN Bus Bootloader for Hercules Microcontrollers (ti.com)

Here they given the settings and supported commands for CAN bootloader:

Please refer the application notes and give the commands in according to it.

--
Thanks & regards,
Jagadish.

Yes, I believe this is what I am looking at. I downloaded the code from here: 6.1. Project 0 — Hercules Safety MCUs Documentation.

My question, at this point, is that when initializing the CAN bus, the function ConfigureCANDevice() is used. There are two functions called within it, canInit() and CANMessageSetRx(). The CAN bus does not seem to work properly when CANMessageSetRx() is used, but if I comment that out, the CAN bus seems to work.

What does CANMessageSetRx() do, and can you give me any insight as to why it may be causing issues when it is used to configure the CAN bus on my TMS570?

Hi Tomas,

I think i understood the root cause for the issue you are getting.

Actually, the CAN Rx Msg settings after the canInit function is as below, right?

However, the CANMessageSetRx function is changing the Rx Msg settings to compatible with bootloader protocol. I mean bootloader have a separate protocol, right?

So, it is changing the Rx msg buffer settings as below:

1. Mask Register value = 0x16800000

This means that ID bits will not be used for acceptance filtering (that means all messages can be received to this buffer),.

MXtd and Mdir bits also zero that means these fields in the received message also not used for acceptance filtering.

2. Arbitration register value = 0x16800000

Here we are making ID as all zero's, but it doesn't matter because already we said that ID field will not be used for acceptance filtering and all messages should be received. 

Dir bit 0 that means receive mode, Xtd = 0 that means standard. But again, these fields also don't matter as we made mask bits for these bits also zero that means these fields in receive message also not used for acceptance filtering.

3. Message Control Register = 0x00001080

DLC is zero that means, valid data bytes in the receive message is zero.

So, the above will become the new settings.

And you should also know that the bootloader code designed in such way that it will respond to the below commands only.

If you receive any other commands than above, then bootloader will simply again go back to the PacketRead function, and it will get stuck at the NWDATx falg.

I think this is the exact behavior happening in your case, i think you are just assuming the settings that given in HALCoGen are the final settings and you are trying to communicate with bootloader, so may be that is the reason it always stuck at the NWDATx in your case.

And also remember that the command filed is not data field, if you verify bootloader code then the command field is nothing but higher 12bit in the received 29bit ID.

That means it will extract the bit ID[29:18] in the received message and used as command.

So, to respond this bootloader, we should first send the PING command

that means the ID[29:8] in your transmitted packet from PC should have the 0x5A1 and data field can be zero.

To learn more details about this, you should refer the bootloader code and application note i shared.

To send application notes to this bootloader you should use the PC side example.

These will be helpful to send the application image easily from the USB to CAN, for more details refer the application notes that i shared.

--
Thanks & regards,
Jagadish.