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.

TMS320F280037C: MCAN Module not configuring correctly and fails to transmit

Part Number: TMS320F280037C

Tool/software:

I am encountering some erroneous behavior during configuration and communication using the MCAN module. 

The MCAN module configuration setup in my application follows the general setup sequence found in the example projects for mcan (such as mcan_ex7_classic_transmit.c), specifically the MCANConfig function. However, after calling MCAN_setOpMode(MCANA_DRIVER_BASE, MCAN_OPERATION_MODE_NORMAL), I am not seeing the MCAN_CCCR.INIT bit transition from 1 to 0. I am waiting at least 11 consecutive clock cycles for the register field to update per the manual and it still does not update accordingly.

Consequently, when I try to initiate a message transmission, the MCU fails to do so. Specifically, when I write to MCAN_TXBAR indicating a buffer add request, I see that the MCAN_TXBRP register updates to 1 for the buffer I am trying to send the message out on, but the applications just hangs at this point because the MCAN_TXBRP bit never gets set to 0 indicating that the message was transmitted. I am assuming that this is related to the issue encountered above where INIT is not getting reset as well.

Additional Info: The clock source used is the peripheral system clock and this is divided down to a 40MHz for the MCAN clock.

Couple of questions:

  • Has the behavior with the MCAN_CCCR.INIT bit ever been seen before? Is there any other process interacting with the INIT bit that would be holding it to 1 despite my application writing it to 0?
  • Is there a reason why the message in the transmit buffer would not be sent out once the MCAN_TXBRP bit is set for that associated buffer?
  • Not observing the issue with MCAN initialization routine in the examples on CCCR.INIT bit.  In the examples, function MCANConfig() puts the MCAN in initialization mode through function call below:

    MCAN_setOpMode(MCANA_DRIVER_BASE, MCAN_OPERATION_MODE_SW_INIT);  // set CCCR.INIT bit to '1'

    then immediately followed with polling for the bit to clear:

    while (MCAN_OPERATION_MODE_SW_INIT != MCAN_getOpMode(MCANA_DRIVER_BASE))
    {}

    Can you try polling method instead?

    Regards,

    Joseph

  • Hey Joseph,

    I am actually using that polling method as you describe. It appears that the CCCR.INIT bit is flipping momentarily from 1 to 0 to get past the loop below:

    while (MCAN_OPERATION_MODE_NORMAL != MCAN_getOpMode(MCANA_DRIVER_BASE))
    {}

    However, the CCCR.INIT bit immediately returns to 1 after leaving this loop. It seems to be that something else is acting upon it to force it to revert to 1 for some reason.

    I am also seeing the CCCR.CSR and CCCR.CSA bit being set when I make the MCAN_Init() function call. Looking at the Technical Reference Manual, the these bits should only be set if a clock stop request is asserted, which should only be set by calling MCAN_addClockStopRequest(MCANA_DRIVER_BASE, 1U); However, I am not calling this function.

    I did notice that if I set the MCAN_InitParams structure members wkupReqEnable, wkupReqEnable, and emulationEnable to 0x1U, then I can get all CCCR.INIT, CCCR.CSA, and CCCR.CSR to clear after calling MCAN_Init. Unfortunately, this still doesn't fix my problem because when I try to initiate a transmission, I am still not seeing any traffic on the bus using a CANbus montitor tool and the PSR.LEC value is 0x7 indicating that No Change has occurred on the bus. The PSR.ACT is 0x1 indicating that the bus is just sitting idle and the PSR.EW and PSR.EP are both 0.

    I am using the method below to transmit a frame, which was taken basically entirely from the example projects (tx_buf is type MCAN_TxBufElement and bufNum is 0U indicating buffer 0):

    MCAN_writeMsgRam(MCANA_DRIVER_BASE, MCAN_MEM_TYPE_BUF, bufNum, tx_buf);

    MCAN_txBufAddReq(MCANA_DRIVER_BASE, bufNum); 

    while(MCAN_getTxBufReqPend(MCANA_DRIVER_BASE)) {}; 

    Is there something else I should be doing in order to successfully transmit from a dedicated transmit buffer?

    Could there be something else affecting the clock stop logic is preventing messages from being sent?

  • Hi Jacob,

    Can you run mcan_ex7 example by itself first and we'll try to backtrack why it MCAN init is not working for your application?  If you run mcan_ex7 what is the receiving node?  Do you happen to have a CAN analyzer that is receiving the data from F280037 device or is it some other CAN node?  One other thing, what hardware are you using?  Is it the F28003x LaunchPad or is it a custom hardware design?

    Sorry for asking more questions but wanted to start on a known working setup and example first before trying to isolate what may be causing MCAN not to properly inirialize.

    Thanks.

    Joseph

  • Hi Joseph,

    It turns out that that I was not following all of the initialization steps of mcan_ex7. I was not calling Device_initGPIO() which, in turn, calls GPIO_unlockPortConfig() to unlock the pin locks of the GPIO pins for Ports A, B, and H. After I added this function call into my initialization sequence, I am no longer seeing the MCAN errors i mentioned in my previous posts. I am able to send and receive with no issues now. As I understand it, if GPIO_unlockPortConfig is not called, then the GPIO pins cannot be configured to other functions, such as MCAN RX/TX use and among other things.

    Thank you for your assistance.