TMS320F280039C: MCAN multiple transmissions

Gesur ARIF said:

so it flags my 2nd PDO as cancelled in MCAN_TXBCF,

Cancellation only happens when the corresponding bit is set in MCAN_TXBCR Register. Is your code writing to this register?

Gesur ARIF said:

Is this the only way to transmit PDOs/Buffers one right after the other?

This depends on the application. C2000ware example is a simple use-case that shows how to transmit data from the MCAN module.

Gesur ARIF said:

To be noted that transmitting those PDOs/Buffers does not trigger an interrupt (as intended and configured).

Did you check your code with the interrupt example in C2000ware?

Gesur ARIF said:

I had to write in CANTA (Transmission Acknowledge Register) the corresponding message box that I wanted to transmit

The eCAN and MCAN are completely different modules. The TXBAR bit gets cleared after the transmission is complete. Can you check this bit before initiating the next transmit?

I have a couple of additions based on the response given by my colleague. 

Gesur ARIF said:

MCAN_TXBAR |= SECOND_PDO

Are the Tx Buffers being used for both PDOs the same or are they different? Ideally, you should not run into any issues in adding requests for two Tx Buffers in MCAN_TXBAR. 

First off, while running this code, is your device connected to any receiver? Not having any receiver in the network to respond with an ACK, can cause issues in the communication. 

Gesur ARIF said:

Is this the only way to transmit PDOs/Buffers one right after the other?

The optimal way to transmit messages in a desired order is to use the Tx FIFO. In case of the Tx Queue, the message with the lowest CAN ID is transmitted first, in case multiple messages are simultaneously ready for transmission. 

Gesur ARIF said:

To be noted that transmitting those PDOs/Buffers does not trigger an interrupt (as intended and configured).

Could you provide more information regarding this? Which interrupts have been set / are expected? Is the transmission occurring successfully in the case where the interrupt is not observed? Is there a receiver that has been connected in this setup?

Thanks. 

Hareesh Janakiraman said:

Cancellation only happens when the corresponding bit is set in MCAN_TXBCR Register. Is your code writing to this register?

I guarantee that I do no writings in register MCAN_TXBCR.

This issue happens only when I have another device, CANOpen compatible in the network. Using only my device with my attempt of configuring the MCAN module and a CAN analyzer, the issue does not occur. TXBCF gets set, irrelevant of whether I am using dedicated Tx Buffers/ Tx FIFO buffers or Tx Queue Buffers.

Hareesh Janakiraman said:

Did you check your code with the interrupt example in C2000ware?

The interrupt is not an issue. I just wanted to mention that sending these PDOs doesn't trigger an interrupt because I decided to NOT configure them to trigger an interrupt.

Hareesh Janakiraman said:

The eCAN and MCAN are completely different modules. The TXBAR bit gets cleared after the transmission is complete. Can you check this bit before initiating the next transmit?

Checking this bit will modify a lot of my higher level protocol logic. I want to do this as last solution, that's why I came here to ask these questions and to confirm the functionality of the new MCAN module.

Sahil Deshpande said:

Are the Tx Buffers being used for both PDOs the same or are they different? Ideally, you should not run into any issues in adding requests for two Tx Buffers in MCAN_TXBAR. 

The PDOs refer to the same object. They have different COBids, but are configured similar in the buffers, the only difference being the length of the message.

Sahil Deshpande said:

First off, while running this code, is your device connected to any receiver? Not having any receiver in the network to respond with an ACK, can cause issues in the communication. 

I've made 2 tests.
One with only a CAN analyzer. The buffers were transmitted as expected.

I connected another drive that is compatible with CANOpen protocol and I kept my analyzer in the network.

With the other drive compatible with CANOpen protocol, my drive which has my attempt of configuring the MCAN module presents this issue.

Sahil Deshpande said:

Could you provide more information regarding this? Which interrupts have been set / are expected? Is the transmission occurring successfully in the case where the interrupt is not observed? Is there a receiver that has been connected in this setup?

Ignore the interrupt. I didn't configure the buffer to trigger an interrupt when transmitted and wanted to give you this information.That's all.

I've tried sending more Tx buffers by having different writes to TXBAR one right after the other
void sendPDOs (pdo_index)
{
   McanaRegs.MCAN_TXBAR.all = pdo_index;                   // I'll call this buffer 1 when pdo_index = 1 and buffer 2 when pdo_index = 2.
   McanaRegs.MCAN_TXBAR.all = pdo_index << 1;          // buffer 1 + 1 = buffer 2 or 3
   McanaRegs.MCAN_TXBAR.all  = pdo_index << 2;         // buffer 1 + 2 = buffer 3 or 4.
}

This is not the actual code, just an example similar to my code. I'll develop on the behavior of this particular code.

These 3 messages get transmitted sometimes. Let me explain.

I don't know what dictates it, but I believe that the Tx Scan.

This sendPDOs function is called in my infinite loop based on different conditions. If I send a command, this function will be executed 2 times in the same loop of infinite loop, with different pdo_index values.

I expect to see 6 messages on CAN analyzer. 
I see, depending on I don't know what (probably the Tx Scan), 3 or 4 messages, 6 only if I put a breakpoint right before the 1st instruction, I resume and keep the breakpoint there. If I remove it and resume the program, not all 6 buffers will be sent.

But when I put my breakpoint at McanaRegs.MCAN_TXBAR.all = pdo_index << 2; I have the following behavior.
Buffer 1 gets sent, program pauses at buffer 3 (buffer 2 sometimes gets sent, other times not).
Buffer 3 gets sent.

At the 2nd call of function, buffer 2 (different pdo_index) gets sent, program pauses at buffer 4 (buffer 3 not sent), then when I resume it, last buffer (4) gets sent.

I am not using step intos, step overs, I am using only resumes when leaving a breakpoint.

The behavior is the same, regardless whether I have a mixed configuration of
Dedicated Tx Buffers with Tx FIFO buffers.
Dedicated Tx Buffers with Tx Queue buffers.
Dedicated Tx Buffers only.

This functionality is provided in eCAN module.

Why doesn't the MCAN module provide the same functionality? Seems to be a limitation of it.

Hi Gesur,

MCAN implementation in the F280039x device closely follows the spec implemented by Bosch so the best way to queue message transmission is to use TX FIFO as mentioned by Sahil.

Regards,

Joseph