• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 82 subscribers
  • Views 210 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.

TMS320F280025C: CAN TX issue when user a timed transmission

Steven Shenker
Intellectual 930 points

Part Number: TMS320F280025C

Tool/software:

Hi there,

I have been successfully sending and receiving CAN by calling my CAN_receive_routine() and CAN_send_routine() in my main loop. The  CAN_send_routine()  simply contains a bunch of CAN_sendMessage() message calls.

I am not using DMA and not using interrupts. I have two questions:

Q1. For some reason when I try and move my CAN_send_routine() to a 1ms task (which I am using for another process as well), I get an assert error when executing.

I looked up the error in the map file and it looks like can.obj which I assume means can.c file? The line number is 487 which is:

  ASSERT((msgCtrl & CAN_IF1MCTL_DLC_M) == msgLen);

This is strange because I have never before had a DLC issue. I tried commenting out this ASSERT Line but for some reason I still get the assert error with the same line number. Any idea what could be happening here?

Q2. Does CAN_sendMessage(uint32_t base, uint32_t objID, uint16_t msgLen, const uint16_t *msgData) block the CPU while sending? I noticed a large slowdown in my 1ms task when simply adding 1 of these function calls per 1ms execution. I had assumed they would not require any processing due to the mailbox functionality. Do I need to enable DMA or anything else?

Thanks in advance!

Steven

  • 0
    TI__Mastermind 42780 points

    Hi Steven,

    When DLC check error is happening, is it possible for you to check register CAN_IF1MCTL for the DLC value and compare it against what is against what is passed by CAN_sendMessage().  This could be an indication that the 1ms task where CAN sending function is added prevents updating of the CAN peripheral registers.

    CAN_sendMessage() should not block the CPU since writes to the CAN interface registers initiate message transfer from the mailbox to the CAN core and out to the bus, which is independent of the CPU.  If you look inside the API though, there is a while loop that polls for busy bit (CAN_IF1CMD_BUSY) as soon as the CAN_IF1MCTL  value is updated.  Could be possible that the API is spending more time with the polling of the busy bit.  If this is the case and you also get persistent DLC comparison failure in the 1ms task, maybe there is some instruction before the 1ms task that is holding the CAN module from updating the registers.

    Have you tried using CAN ISRs instead for the sending routine?  This will only send the CAN frames only when it detects valid changes in the mailbox, like when new data is available.  This might be more efficient than time based task.

    Regards,

    Joseph

  • 0 in reply to Joseph Casuga
    Intellectual 930 points

    Thanks Joseph, I will definitely look into the ISRs for sending. I managed to fix the CAN_sendMessage() issue by replacing it with CAN_sendMessage_updateDLC(), even though the DLC wasn't a problem before. Anyway happy that this solution works.