TMS570LS3137: CAN or Ethernet Bootloader Examples adapted to a PGE Part

If you add a breakpoint to the following section in CAN bootloader, can you get any command input from external host?

while(1)
{
//LITE_TOPRIGHT_LED;

ulBytes = 0;
ulCmd = PacketRead(node, g_pucCommandBuffer, &ulBytes);

ucStatus = CAN_CMD_SUCCESS; // 0x00
switch(ulCmd)
{

//
// This is a ping packet.
// This command is used to receive an acknowledge command
// from the boot loader indicating that communication has been established.
// This command has no data. If the device is present it
// will respond with a CAN_COMMAND_PING back to the CAN update application.
// CAN_COMMAND_PING = 0x1F02,0000
// ACK = 0x1F02,0100
case CAN_COMMAND_PING:
{
    PacketWrite(node, CAN_COMMAND_ACK, &ucStatus, 1);
    break;
}

After using the breakpoint I was able to confirm that no message was being received.  I checked that the cables were correct from the NI USB-8502 I was using and then tried changing the little_endian definition from 1 to 0.  I was then able to see CAN messages on the bus.  The PING command on the external code no longer times out, but I am now getting an error message as follows:

initialized successfuly on CAN0 ...

Sending COMMAND_PING command ...

NI-CAN: (Hex 0xBFF62105) The size or length that you provided is invalid (too small or large), and the operation could not continue. Solution: Read the function description and verify that you provide a valid size (or length).

Source = ncReadMult

It looks like that there is no CAN message is transmitted from the host. Attached please find my example VC++ project on PC host size.

7633.TMS570LS_canBootloader_Test.zip

I get the same error

I can confirm the micro receives the ping command, reads it correctly, and attempts to send back the ACK

It appears the error is the result of this call...

Status = ncRead(RxHandle, sizeof(ReceiveBuf), (void *)ReceiveBuf);
if (Status < 0)
{
PrintStat(Status, "ncReadMult");
}

Hi,

The baudrate in host side is 500k. The TMS570 DCAN0 should run in same baudrate.

When PacketWrite(node, CAN_COMMAND_ACK, &ucStatus, 1) is called, do you see the transmitted data on CAN bus?

I didn't change the baudrate in the can.c or can.h files, so It should be set to 500k still.  I inserted the PacketWrite command just before the switch and monitored the bus.  This is the result.

I can now see that the ID of 1446(Dec) is the correct 0x05A6 ACK.  Is the fact that the Micro receives the 0x05A0 Ping and responds confirms that the USB-8502 is sending and receiving at the correct BAUD rate, correct?

I did a test, there is no problem.

1. The bootloader should be executed first, be waiting for the PING command from the host

2. Then project on Host side starts execution.

Is this a problem with how my Visual Studio is compilling the code? My project on the host side is recieving the CAN message in, but erroring on the ncRead call. 

I have been using Visual studio 2019 to build and compile, which requires me to upgrade the project and compile tools.

I have found and installed Visual Studio 2010 and run your external code.  The code successfully sends the ping to the TMS570, and the TMS570 identifies the ping and sends the ACK back.  The test code then crashes during the ncRead call, exactly as it did in VS2019

initialized successfuly on CAN0 ...

Sending COMMAND_PING command ...

NI-CAN: (Hex 0xBFF62105) The size or length that you provided is invalid (too small or large), and the operation could not continue. Solution: Read the function description and verify that you provide a valid size (or length).

Source = ncReadMult

Using break points in both the MCU code I can give the following additional feedback.  With the MCU code running I see the ping come in, I see it parsed by the MCU, and I see it respond on the Can Bus.  The following is the message sent back when monitering that bus.

The PC side code current state changes to 3

The RecieveBuff, however, doesn't change.

and the size error is thrown.

With the CAN cable disconnected, the Current State stays 0 and the Ping times out.

Why can I see the message on the CAN bus monitor at 500k but the PC Side code cannot seem to read it?

I don't know what causes the issue. Can you try longer waiting time?

The example code uses 3 seconds:

#define NC_DURATION_3SEC 3000 

The example uses the driver for NI USB-CAN 8473, please make sure the library you downloaded is correct for your CAN adaptor.

I was successful in establishing 2 way communications with the PC side code.  The NcRead call was the problem. I changed all the ACK read requests to use the following NcReadMult instead.

Status = ncReadMult(RxHandle, sizeof(ReceiveBuf), (void*)ReceiveBuf, &ActualDataSize);

With communications established, I was able to download our binary file (compiled to start at address 0x00010020) and transmit it to our MCU.  The update check, however fails with the UpdateStatusAddr showing the following value.

Does our image need to set the 0x5A5A5A5A value, or does the bootloader do that?

The bootloader writes the flag to 0x10000 after the binary image has been programmed successfully.

Adding a bunch of debug statements, I can now see what is failing.  While the comands are being transmitted properly, it appears the data is not.  The external code is receiving ACK from the MCU and going about its tramsmit and signalling success.  The MCU is failing the address and size though and not accepting or writing any data.  This is the external code sending the address.

The address (in DEC form) and size are correct, as well as the breakdown.  This is what is received by the MCU

The g_pucCommandBuffer[] elements are all 32, leading to an incorrect conversion and incorrect address and size.  This results in the g_ulTransferSize being set to 0 and nothing being written.

In troubleshooting the size I have determined that the routine to read the CAN DataA and B registers was not working correctly.

pusData = (uint8_t*)pucData;

/** - Copy RX data into destination buffer */
for (i = 0U; i < ulBytes; i++)
{
#if ((__little_endian__ == 1) || (__LITTLE_ENDIAN__ == 1))
*pusData++ = node->IF1DATx[i];
#else
*pusData++ = node->IF1DATx[g_ulCanByteOrder[i]];

#endif
}
GADataBuffer[0] = node->IF1DATx[3U];
GADataBuffer[1] = node->IF1DATx[2U];
GADataBuffer[2] = node->IF1DATx[1U];
GADataBuffer[3] = node->IF1DATx[0U];
GADataBuffer[4] = node->IF1DATx[7U];
GADataBuffer[5] = node->IF1DATx[6U];
GADataBuffer[6] = node->IF1DATx[5U];
GADataBuffer[7] = node->IF1DATx[4U];

the pusData was never getting the actual data in the register and therefor the g_ulTransferSize and g_ulTransferAddress were filling with all '32's.  I  was able to parse the data with my own buffer correctly and feed that into the Address and Size. 

The code then errored with the size check as the ulWholeFlashSize was coming out at 0.  I eliminated the size address check and now I am geting an access violation.

It seems that the bl_Flash functions must not be parsing the flash defines for my chip correctly.  Can you think of anything that would be causing this?

Sorry, I don't know what causes this problem.