TM4C129DNCZAD CAN0 Problems

  SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOT);

  GPIOPinConfigure(GPIO_PT0_CAN0RX);
  GPIOPinConfigure(GPIO_PT1_CAN0TX);

  GPIOPinTypeCAN(GPIO_PORTT_BASE, GPIO_PIN_0 | GPIO_PIN_1);

Hi,

We ordered the DK-TM4C129XNZAD development kit.  I hooked a CAN transceiver to it and James loaded the code on it and the CAN communication was working.  This validates that the code he wrote is good.

I took the exact same CAN transceiver that was working on the eval kit and hooked it to the prototype and it doesn't work.  He is able to program it with code where the PT1/CAN0Tx and PT0/CAN0Rx pins are set high as GPIO pins, and also another set of code where it is set low as GPIO pins.  This validates that my CAN0Tx and CAN0Rx connections are good underneath the BGA.  This also validates there isn't something shorting the pins (even though I could not measure a short anyway).

This still does not explain why the chip is able to drive the CAN0Tx line only when the processor CAN0Tx pin it is floating (but still connected to the scope so I can see it).  It will not drive CAN0Tx low when it is connected to the input of the transceiver circuit.  The data on the CAN0Rx is good coming in from the network.  The Tx pin is high and not holding the bus.  Why is this chip not able to drive the signal low on PT1 as CAN0Tx but it can as GPIO PT1?  The code works on the eval kit so this is not a code issue.  There is something wrong with the layout, this physical processor, or the assembly. 

I even tried replacing all my power bypass caps from 0.22uf up to 4.7uf (including the 2 core caps) in concern that there was not enough available power to the chip, but that made no difference.

I am still in dire need of assistance on this.  Thanks for your help.

Kevin

Hello Kevin,

Kevin Wood said:

This still does not explain why the chip is able to drive the CAN0Tx line only when the processor CAN0Tx pin it is floating

Do you mean the CAN Transceiver or TM4C driving CAN0TX?

Regards

Amit

I have a wire coming off the prototype board that is connected only to the CAN0Tx processor pin (I have cut the traces on the top layer that goes to the can transceiver on the board for both Tx and Rx).  The CAN0Tx wire has a quick disconnect terminal on it which connects to a quick disconnect terminal on the can transceiver input wire.  I am using the external CAN transceiver because I know it is working on the eval board. 

When I put the scope on the processor pin for CAN0Tx, the CAN0Tx signal will always stay high when the two wires are connected.  When the wires are disconnected from each other, the processor pin will start attempting to drive low like it wants to communicate out to the bus, but it cannot because it is disconnected.  It seems to me like something internal to the processor is preventing the signal from driving low, but I don't know why.  I even had tried a couple of weeks ago putting a high speed JFET input op amp voltage follower in between the CAN0Tx line and the CAN transceiver input and that made no difference. 

I got layers files from our headquarters where the layout was done.  I can send it to you if you wish to see it. 

Pardon if this has been included - but cannot you (temporarily) switch to another CAN pin pair - attach to that same CAN Xcvr - and repeat your test?
 
I recall a client of ours having similar issues w/the "higher Port CAN sub-systems" w/TM4C129.  (higher port = higher alpha listing)

One more thing - this not covered - your extensive report:  Have you monitored the 3V3 during operation of this particular CAN?   And any (other) lower voltage MCU pins - which may be exposed & capable of being monitored?

Are you absolutely certain that no (unwanted/unrecognized) signal paths and/or connections exist - which "burden" those CAN signal lines?

Does your code run up to - and thru - a brief CAN output sequence - normally?   Or does it "hang?"

Should the CAN Xcvr perform "normally" when excited by another CAN Port - your (failing) CAN port is "highly" suspect!
 
Applaud your "GPIOing" those CAN pins - to validate that a (proper) signal can be generated - and does fully exercise your CAN Xcvr. I'm betting on that specific MCU CAN Port being, "Not good for Gov't Work!"   (CAN in this instance)

After finding the discrepancy in the AFSEL and PCTRL registers that gave us some hope, but the Tx line is still behaving the same way.  The CAN0Tx line still never pulls low.  Are there any other registers you can think of that we can check?  Even without that change, the code worked on the superset device.  I am still leaning towards having a couple boards reworked with the superset device.

Might you assist us by "locking down" your earlier report that, "When re-purposing those 2 CAN pins to GPIO Outputs - and making no other board nor program changes - your CAN Xcvr (then) evidenced proper operation!"   Are all of those facts true?

If all of the above is true - have you "ohmed out" that CAN_TX line - to both VCC and Gnd?   I cannot recall if a pull-up R is on CAN_TX - if one is - measure to insure its value is not far lower than expected.

If any other CAN modules are present - and working - you may wish to scope both CAN_TX & CAN_RX - and insure that the errant CAN channel well matches those levels obtained from "working CAN channels..."

TI RTOS version 1.21.0.9

Tivaware 2.0.1.11577a

Well, the CAN0 has never had proper operation.  When repurposing the same two pins as GPIO, they are correctly driven high and low, with optimum voltage levels, so they work perfectly.  That doesn't test CAN0 though, just the pins.

I have ohmed out the Tx line, and it is not shorted to 3.3V or GND (measures with it off +50Kohms).  I have also tried both a 10K pullup and a 10K pull down and that had no impact.  We have never needed it in the past, nor does it work on the eval board.

We do not have the second CAN1 interface working because our code that uses it will not work until the first CAN0 network is working.

It took a while, but I installed CCS6 on my machine and imported the project.  When I program the code on our prototype board I get the same problem - no Tx Signal on CAN0.  It just stays high.  I can also still see traffic coming in on the CAN0Rx line.  I am really leaning towards this being a silicon issue at this point.  I am still looking forward to any potential software solutions to this, but I am getting skeptical of that at this point.  I am open to suggestions.  I am going to send 2 boards back to the vendor for a superset device swap.

Hi Amit,

Have you found anything new yet in the registers for CAN0 or Port T?

I have gotten two boards with the processors replaced with the superset device, and I still have the same problem.  This tells me it is probably something with the layout but I am still having trouble finding it.  I feel like I have checked all my pin connections against the eval board.  Since we know we have been able to toggle the pins as GPIO I know the connections are ok to the CAN transceiver.  I have the evaluation kit (which is working) and am trying to figure out how to put CAN0 into test mode on the good board, so that I can try it on the bad prototype board.  I want to put the CAN0 Tx line low manually while configured as CAN.  I change the CAN0 CAN_CTL_TST to be 1, but when I attempt to change CAN_TST_TX I just get an error window that pops up:

" has encountered a problem.

An internal error occurred during: "",

(and under details:)

An internal error occurred during: "".

-1

Why can't I write to CAN_TST_TX?

Hi,

I think you are testing each board alone instead using a real two wire bus and another good working node. An answer to your question(s) here may be found on page 17 of the attached document (CAN2.0B rules...)

2011-09-06 Texas Instruments CAN PHY Technical Training.pdf

Yes that is exactly what I tried to do.  After that wasn't working I even tried doing direct writes using

//HWREG(0x40040000) = 0x8E;

//HWREG(0x40040014) = 0xC0;

and it ended up making all of the registers of the CAN module completely unreadable.  I suppose I wrote the wrong values, but I had to do a full erase and revert those changes to be able to read the CAN module registers after that.

The same thing happened as before, where I could not read any of the CAN0 registers when I hard code that in.  I had to revert changes, do a full erase and reprogram to get it to work again.

Another interesting symptom, is the CANTx is low when the device is fully erased.  Perhaps in full erase the hardware defaults as GPIO and not CAN0 so it can go low at that time.