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.

TM4C129DNCZAD CAN0 Problems

Other Parts Discussed in Thread: TM4C129DNCZAD, TM4C129ENCPDT, TM4C129XNCZAD, TM4C1299NCZAD

Hi,

We have done about 5 boards successfully with TM4C1299ENCPDT (QFP) using CAN, and have the same CAN circuit that has been used many times before.  We have a new layout that uses TM4C129DNCZAD (BGA) and we cannot seem to get the CAN0 interface to work correctly.  As far as I can tell, I cannot find any problems in my layout, but I am not ruling anything out.

Here are the symptoms:

Board #1

-Data comes in as expected on the CAN0Rx line from the CAN bus.

-CAN0Tx line stays high.  No change in the state of CAN0Tx.  I tried using a pull-up resistor or a pull down resistor and no difference was seen.

-Cut the connections to the onboard CAN transceiver (CAN0Rx and CAN0Tx).  I wired in a known good external CAN transceiver module straight to the processor.

-After breaking the connection between CAN0Tx and the Tx input of the CAN transceiver circuit, the Tx input can be toggled high and low, so it is not shorted.  Holding the input High lets bus traffic flow, and grounding it holds the bus.  This is what I expect to see.  Also after that connection was broken, CAN0Tx will drive low over and over again to attempt communication, but it will not work because it is not actually connected.  This also seems correct.  However, if you connect them together again, the CAN0Tx signal just stays high.  It is as if the pin cannot drive the input the transceiver circuit.

-I could not find any specific input impedance of the inverter (that the processor CAN0Tx connects to) in its data sheet, however I assume it should be very high.  This is the same transceiver circuit we always use but a new processor.  I wanted to do a low drive strength test of the processor pin, so I externally took an op amp (AD822 with super high impedance inputs) and wired it as a single supply operation voltage follower with the CAN0Tx tied to the input, because if nothing else it should at least be able to drive the op amp.  When I did this, the op amp output would follow the pulses on the Tx line, but that was still with the output of the op amp floating.  When I connect the output of the op amp to the Tx input on the CAN transceiver circuit, the CAN0Tx (op amp input and output) driving the transceiver stay high again.  The transceiver inverter input has already been verified that it is not shorted.  My mind is totally boggled on this one.  I have no idea if this is a hardware or software problem.

Board #2

This time I used the onboard CAN transceiver, but cut the CAN0Tx trace right before the CAN transceiver like I did before.  I got the exact same results, except when I float the CAN transceiver Tx input, CAN0Tx doesn't try to pull low as much as on board #1.  If I touch the wire to the floating transceiver input with my hand, the Tx line will start attempting to pull low, but when I let go it stops.  Also, when I connect the lines back together again I get the same problem where they just stay high.  I also tried inserting the op amp circuit and got the same results as board #1.  I verified the transceiver input is not shorted and that I can toggle it. 

The behavior is very strange.  I am not ruling anything out.  We have checked all the W10 and V10 GPIO and AFSEL registers for configuring CAN0 and they all look correct.  I cannot find anything wrong in the layout.  I cannot find any bad connections or voltages. 

Any suggestions would be very helpful.  I can have the software engineer provide the initialization code for CAN0 if that is helpful.

Thanks for your time.

Kevin

  • Hello Kevin

    When the device is fully erased the IO changes state to the default mapping which would be input only mode.

    Regards
    Amit
  • Is it possible that the CAN0 controller is stuck in some sort of interrupt state?

    R CAN0_CAN_CTL 0x0000000B 0x0000000E
    R CAN0_CAN_STS 0x0000000B 0x00000061
    R CAN0_CAN_ERR 0x0000000B 0x0000FF00
    R CAN0_CAN_BIT 0x0000000B 0x000067FB
    R CAN0_CAN_INT 0x0000000B 0x00008000
    R CAN0_CAN_TST 0x0000000B 0x00000080
    R CAN0_CAN_BRPE 0x0000000B 0x00000000
    R CAN0_CAN_IF1CRQ 0x0000000B 0x0000000F
    R CAN0_CAN_IF1CMSK 0x0000000B 0x000000F3
    R CAN0_CAN_IF1MSK1 0x0000000B 0x00000000
    R CAN0_CAN_IF1MSK2 0x0000000B 0x00002000
    R CAN0_CAN_IF1ARB1 0x0000000B 0x00000000
    R CAN0_CAN_IF1ARB2 0x0000000B 0x0000C000
    R CAN0_CAN_IF1MCTL 0x0000000B 0x00001488
    R CAN0_CAN_IF1DA1 0x0000000B 0x00009BEE
    R CAN0_CAN_IF1DA2 0x0000000B 0x0000AF7F
    R CAN0_CAN_IF1DB1 0x0000000B 0x0000DF8B
    R CAN0_CAN_IF1DB2 0x0000000B 0x0000DCFC
    R CAN0_CAN_IF2CRQ 0x0000000B 0x00000001
    R CAN0_CAN_IF2CMSK 0x0000000B 0x00000000
    R CAN0_CAN_IF2MSK1 0x0000000B 0x0000FFFF
    R CAN0_CAN_IF2MSK2 0x0000000B 0x0000FFFF
    R CAN0_CAN_IF2ARB1 0x0000000B 0x00000000
    R CAN0_CAN_IF2ARB2 0x0000000B 0x00000000
    R CAN0_CAN_IF2MCTL 0x0000000B 0x00000000
    R CAN0_CAN_IF2DA1 0x0000000B 0x00000000
    R CAN0_CAN_IF2DA2 0x0000000B 0x00000000
    R CAN0_CAN_IF2DB1 0x0000000B 0x00000000
    R CAN0_CAN_IF2DB2 0x0000000B 0x00000000
    R CAN0_CAN_TXRQ1 0x0000000B 0x00000000
    R CAN0_CAN_TXRQ2 0x0000000B 0x00000000
    R CAN0_CAN_NWDA1 0x0000000B 0x00000000
    R CAN0_CAN_NWDA2 0x0000000B 0x00000000
    R CAN0_CAN_MSG1INT 0x0000000B 0x00000000
    R CAN0_CAN_MSG2INT 0x0000000B 0x00000000
    R CAN0_CAN_MSG1VAL 0x0000000B 0x00004000
    R CAN0_CAN_MSG2VAL 0x0000000B 0x00000000

  • Hello Kevin,

    No. Even in case of interrupt, the debugger and CPU can still access the device registers

    Regards
    Amit
  • I have some new information.  One of the few differences I can find in the BGA system and power connections between the evaluation board and the prototype board is the crystal oscillator.  The eval has 25MHz and the proto has 16MHz.  I am suspect of this all coming back to a clocking issue somewhere

    I added "| SYSCTL_XTAL_16MHZ"

    to get a valid clock configuration:

    SysCtlClockFreqSet((SYSCTL_USE_PLL | SYSCTL_OSC_MAIN | SYSCTL_CFG_VCO_480 | SYSCTL_XTAL_16MHZ), 120000000);

     

    This did not fix the issue.

     

    Another thing I found was sometimes RCGCCAN at 0x400FE634 was =0x00000000.  Is this a problem?

     

     

  • Hello Kevin,

    Yes, that is a problem. The RCGCCAN must be set to 0x1 for enabling CAN0, 0x2 for CAN1 and 0x3 for CAN0 and CAN1. Do make sure that corresponding SYSCTL.PRCAN bit is set to 1 before accessing the CAN Module.

    Regards
    Amit
  • I fixed the RCGCCAN issue as well and it did not fix the problem.  PRCAN is also set to 0x01.  Interestingly enough I see similar symptoms on the evaluation board if I set the clock speed to 16MHz when the board actually has 25MHz. 

    This still seems like this is a clocking issue to me.  Is there a way I can validate what the system clock speed actually is?  I don't believe that it is getting set correctly even with the "| SYSCTL_XTAL_16MHZ" added into the function.

  • Hello Kevin,

    You can create a small PWM code, where the PWM outputs a PWM signal at 1/1000 of the System Clock. Knowing what the PWM output is, the System Clock and the VCO can be gauged.

    Did you check if the MOSC is oscillating correctly?

    Regards
    Amit
  • OK I will try that. I will be receiving 25MHz crystals this morning, so I will probably end up trying that swap first with the 16MHz crystal.

    The main oscillator is working. The code is running, and we have a status led that continuously blinks red because the CAN network is not mapped yet.
  • Hello Kevin

    If the clock is configured incorrectly or is incorrect, then part of the design may work and part may not.

    Regards
    Amit
  • The problem was fixed by changing to the 25MHz crystal. I never got around to writing PWM code but I am just going to switch to the 25MHz crystal. I think that there is something wrong with the clock configuration library because we had it configured right for 16MHz.

  • Hello Kevin,

    If you still have one of the unmodified board with the 16MHz crystal, can you send the clock function and MOSC waveform?

    Regards
    Amit
  • SysCtlClockFreqSet((SYSCTL_USE_PLL | SYSCTL_OSC_MAIN | SYSCTL_CFG_VCO_480 | SYSCTL_XTAL_16MHZ) , 120000000)

    I'll send the scope screenshot shortly.
  • Hello Kevin

    The configuration and the clock scope plot are correct for 16MHz. I cannot explain why it would not work with 16MHz clock.

    Regards
    Amit
  • Is it possible the #define for SYSCTL_XTAL_16MHZ is the wrong value? That is why I was curious to know what the actual system clock was when I had attempted to configure it to 16MHz. I have a feeling there lies the answer to the problem.

    Anyhow all of our other M4 boards are running 25mhz. It so happened that the previous M3 version of this board was running off of a 16MHz clock, but Im just changing it to 25Mhz so I can avoid the problem entirely.
  • Hello Kevin,

    The 16MHz crystal value is used for look up. As I mentioned the PWM divided signal or the SYSCTL Clock divider can be a good method to see what is the system clock.

    Regards
    Amit