MSPM0G3507: can protocol implementation

Hi,

Could you provide more details about the behavior you would like to implement?

-Matthew

Hi,

         As I explained you, we are using the CAN protocol in our project. The issue is that, we are not able to use RX BUFFER with dedicated buffer while we are using the RXFIFO. But we prefer to use RXBUFFER elements to reduce the traffic of the can bus. Because, while using the RXFIFO, we are not able to process as much as soon. Then we cannot debug with the RXFIFO. Hence, I would suggest you to give me an idea to implement the can protocol with RX BUFFER.

Thanks,

Praveen

Hi Praveen,

Thank you for the information. I looked at the provided code, and wanted to know more about how you have implemented your system.

Let's start by trying to narrow down whether or not this could be software or hardware

It sounds like you have created a test case where the transmitter is sending a constant value, but the receiver is occasionally receiving the wrong value.

>>> Could you provide a schematic that shows the termination resistors (and any other connections)?

>>> Have you tested your code on Launchpads/EVMs to test the software with hardware that is validated?

-Matthew

Hi Matthew,

>> I have attached the schematic diagram of the CAN side. Please take a look on to this. 

>>I have used MSPM0G3507 launch pad which does not have CAN transceiver onboard. So, we used the CAN transceiver board which is designed by us. After that It communicates but we observed the same issue on this.

The connection is given below.

Please let me know if anything else is needed.

Thanks,

Praveen

Praveen,

Have you tried to send the same type of data using the example code?

Could you confirm that my understanding is correct? --> Your test case is sending a constant value, but you occasionally receive the wrong value? 

-Matthew

Hi Matthew,

Yes, I have tried sending the same constant data from PCAN explorer to MCU with example code. We observed the same issue. 

Yes, understanding is correct for test case.

In the above trace, the constant value was transmitted for 1 hour, however, we observed the dip (different value).

--Praveen

Hi Matthew,

Could you tell me the Base Address of the RX FIFO element and RX BUFFER?. Because we are going to try with register level code. 

Thanks,

Hi,

The base address of CAN for your device can be found in the data sheet as pictured below. Please refer to the TRM for specifics about the required offsets.

-Matthew

Hi,

How can I read the RX buffer/ RX Fifo element without the API which are provided by CCS. What is the starting address of the above element?

-Praveen

Hi Praveen,

The starting address of the CAN message RAM can be found by taking the base address of the MCAN and adding it to the offset found in syscfg. However, the address found in syscfg (172) is in DEC, so convert it to HEX (0xAC)

0x40508000 + 0xAC = 0x405080AC

-Matthew

Hi Matthew,

Greetings..!

We have resolved the issue which we had raised as a query which related to the CAN communication.

Previous Approach:

We were using tx dedicated buffer for each IDs. Because we thought that if we use dedicated buffer for each IDs will be more efficient and reliable.

But it created an issue unexpectedly .

The below functions are being used in the can transmission side. 

DL_MCAN_writeMsgRam(MCAN0_INST,DL_MCAN_MEM_TYPE_BUF, 0, &TxMsg);

Here, you can see the parameters which are totally depend on the buffer type and buffer number.  Here you can transmit the data through different buffer

by using the different buffer number. 

DL_MCAN_TXBufAddReq(MCAN0_INST,0);

this is function that used to transmit(request to transmit) the data over the can. Here also we mention the buffer number.

As per this, It will not lead any problem.  

How ever, everything is perfectly defined and used, we were not able resolve the issue. 

For your understanding, here i have given a small example code how we implemented the can state machine. 

switch(transmit)
{
case CHARGER_INFO:
                  charger_Info();
                  DL_MCAN_writeMsgRam(MCAN0_INST,DL_MCAN_MEM_TYPE_BUF, 0, &TxMsg_Charger_Info);
                  DL_MCAN_TXBufAddReq(MCAN0_INST, 0);
                  transmit = CHARGE_PROFILE;
                  break;
case CHARGE_PROFILE:
                 charger_Charge_Profile();
                 DL_MCAN_writeMsgRam(MCAN0_INST,DL_MCAN_MEM_TYPE_BUF, 1, &TxMsg_Charge_Profile);
                 DL_MCAN_TXBufAddReq(MCAN0_INST, 1);
                 transmit = CHARGER_INFO:
                 break;
}

Above state machine shows, both the cases are using different buffer number. 

Current Approach:

Now, we are using the single tx buffer for all the IDs. It is working as expected.

switch(transmit)
{
case CHARGER_INFO:
                  charger_Info();
                  DL_MCAN_writeMsgRam(MCAN0_INST,DL_MCAN_MEM_TYPE_BUF, 0, &TxMsg_Charger_Info);
                  DL_MCAN_TXBufAddReq(MCAN0_INST, 0);
                  transmit = CHARGE_PROFILE;
                  break;
case CHARGE_PROFILE:
                 charger_Charge_Profile();
                 DL_MCAN_writeMsgRam(MCAN0_INST,DL_MCAN_MEM_TYPE_BUF, 0 &TxMsg_Charge_Profile);
                 DL_MCAN_TXBufAddReq(MCAN0_INST, 0);
                 transmit = CHARGER_INFO:
                 break;
}

Above state machine shows, both the cases are using same buffer number. 

What is the issue with the first approach and how it got resolved with last approach?

Could you tell us that what the actual problem is?

Thanks,

Praveen

1) It looks like you are using buffer 0 for all of your messages. Is this behavior acceptable?

     a) My understanding is that you want CHARGE_PROFILE in buffer 0, and CHARGER_INFO in buffer 1.

2) When you were testing your initial solution that had the intermittent errors --> were there any other subroutines that could have caused it to hang?

I would try creating a bare-bones setup that only includes the CAN transmission, so you can isolate the problem to the buffer. It sounds like there might be another variable at play.

Hi Matthew,

Hi Matthew,

1) It looks like you are using buffer 0 for all of your messages. Is this behavior acceptable?

     a) My understanding is that you want CHARGE_PROFILE in buffer 0, and CHARGER_INFO in buffer 1.

Reply:

Yes, the function behavior is acceptable. 

Yes, we want to use dedicated buffers. 

2) When you were testing your initial solution that had the intermittent errors --> were there any other subroutines that could have caused it to hang?

Reply:

No, there were no subroutines. 

I would try creating a bare-bones setup that only includes the CAN transmission, so you can isolate the problem to the buffer. It sounds like there might be another variable at play.

Reply:

We have already tried it. The project code had only can transmission and reception. But we faced the same issue. 

The difference between current and previous approach is that no.of buffers we used for transmission, rest of all same. 

Query:

My concern with current approach is " what if the number of transmitted message increases to say 50 messaged".

I suspect using same buffer for all message will cause an issue. What is your opinion?

Thanks,

Does this behavior happen on different devices?

A typical CAN frame includes a CRC to protect against garbage values, so I am not convinced it's a hardware issue yet.

Could you provide the full CCS project file, and a detailed description of your latest setup? I can try replicating your setup, and running some tests of my own. (You can provide this to your TI sales representative via email)

-Matthew