• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 55 subscribers
  • Views 746 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CCS/AWR1642BOOST: Problem with the CAN-FD Driver

Riccardo Spera
Prodigy 40 points

Part Number: AWR1642BOOST

Tool/software: Code Composer Studio

Hi,

In my own CCS Project, I'm trying to send a certain amount of data, 3584 bytes in total, over CAN-FD.

To transmit the data, I divide the total amount of data in 3584/64 = 56 CAN-FD frames of 64 bytes each, which are separately sent to the "CANFD_transmitData" driver function.

In other forum threads I have seen that when using CAN-FD, after having called "CANFD_transmitData" to send the 64 bytes of the first block, is needed a "Task_sleep(1)" to avoid the CANFD_EINUSE error at the successive API calls.

This slows considerably the effective CAN-FD throughput to 64bytes/1ms=512kbits/s.

I've tried to overcome this limit with two different strategies:

1. Using a TI-RTOS Timer with period in microseconds, I have been able to pause the task for less than 1 ms, but the received CAN-FD data are partial and corrupted, bad solution.

2. To have a more interrupt-controlled process, after the first  "CANFD_transmitData" call, I have blocked the task until I receive a message of message TX completion by the MCANAppCallback with the CANFD_Reason "CANFD_Reason_TX_COMPLETION". After the first call, the successive API calls returns the CANFD_EINUSE. This have sense because the interrupt I have used is from the MCAN_TXBTO register, wich just says that the TX has occourred but it doesn't guarantee that I can make a new TX request.

The CANFD_EINUSE occours when the API detects TX pending messages in the TX buffer (the MCAN_TXBRP register). I'm probably wrong or missing something, but I suppose the transceiver to be available after a TX has occourred. Is there a way to know exactly when I can do a new TX request without finding the Transceiver in use? Or I just have to wait this 1 ms with Task_sleep(1)? 

Thanks in advance,

Riccardo

  • 0
    TI__Guru**** 152494 points

    Hi,

    We have some questions that will help us support you.

    1) What SDK version are you using?

    2) Did you start your project from scratch or did you use any of the provided examples: CAN-FD driver unit test, Data over CAN demo...?

    Thank you

    Cesar

  • 0 in reply to Cesar
    Prodigy 40 points

    Hi Cesar,

    1) I'm using the SDK "mmwave_sdk_02_01_00_04".

    2) I started with the mmWave SDK Demo project. I added CAN-FD capabilities to it by following the "Adding CAN Tx and Rx to an Existing mmWave Project" guide. The CAN-FD communication works fine in my AWR1642BOOST: the board sends and receives CAN-FD messages correctly. Actually I have a Task which tries to send those 3584 bytes but without those 1ms sleeps, and here my problem rises.

    Hope it helps,

    Riccardo 

  • 0
    TI__Mastermind 21025 points

    Hi Riccardo,

    Did you get a working solution to this?  The MCAN module has a message RAM that is bigger than the amount of data you wish to send, and a FIFO/Queue mode with 32 Tx elements, so that you should be able to send half of your message (64 bytes * 32 buffers) without too much intervention.  Please check out chapter 22 of the AWR TRM, and the SPI test code found in the ti/drivers/spi/test.  Also, there are registers you should be able to check if you don't see an API that returns the TX status you need (MCAN_TXFQS or MCAN_TXBRP for example).

      -dave