TM4C123AE6PM: CAN Bus, not transmitting

I'm using TivaWare 2.1.4.178 so it doesn't have the TivaWare 2.1.3.156 bug.

More info:  once initialized and both before and after CANMessageSet() is set, CANCTL = 0xE (Error, Status, and CAN interrupts enabled and it's set to normal operation), CANSTS = 0, CANERR = 0, and CANINT = 0.

Any advice on where to look, things to try ?

Thanks

OK, how about suggestions about where I can hire someone that can help me solve this ??

Wow, it seems I've become persona non grata ... I don't know why.

Anyone out there ???

At this point I doubt that anyone will see or care about this issue, but just in case I wanted to add that everything works fine in local loopback test mode.

More grist for the mill; I can force the I/O high and low in test mode.

Before attempting to send a message, the CAN Status register is 0, after trying to send a message it is still 0, and since the transmit interrupt didn't happen it hadn't zero'd it out - and the TxOK bit is not set saying that it didn't go.

Before attempting a transmit the CANTXRQ2 register is 0, after attempt it is 1 (the message object is # 17) indicating it has requested a Tx but is not done.  Remember, everything worked OK in loopback mode.

Hi Doug,

Sorry for the delays but can you help clarify which TCAN transmitter you are communicating with? If it works well in loopback mode my assumption would be the hardware set up is the issue.
Also just to double check in loopback mode did you receive the message properly?

It's a TCAN1472VDRQ1, and I'm looking for the signal coming out of the MPU directly, not on the CAN bus itself.

And I don't see how it can be a hardware issue when I can use the CAN Test Mode to make the signals go high and low.

And yes, in loopback mode I received the message correctly.

I just made a mistake and clicked "This Resolved my Issue", would you please undo that.

Yes, the transmit and received interrupts worked fine in loopback mode.

Re "what register values", can be be more selective of which registers you want me to track?  What I have before any transmit attempt:

CANSTS, Status:  0,  CANIF1CRQ:  0x20,  CANIFMCTL:  0,  CANTXRQ1:  0,  CANTXRQ2:  0

After trying the transmit:

CANSTS:  0,  CANIF1CRQ:  0x11,  CANIFMCTL:  0x988,  CANTXRQ1:  0,  CANTXRQ2:  1  (Message Object 17).

The code is the same for both the loopback test and under normal operation.  If you want I can send you my code and/or schematic.

Thanks, Doug

Is the CAN Rx signal at the MPU expected to be either high or low for the device to transmit - i.e., is it sensing that the CAN bus is on and in an idle state?

Sending the code and schematic would be useful if that's easy.

If it worked in loopback mode I'm curious if it's an issue with the GPIO configuration. Can you send the information on the GPIOAFSEL and GPIOPCTL registers? Just to make sure they are both mapped to configure the CANRX and TX pins.

I'll double check the register values you have sent and make sure they are as intended.

Port B:  GPIOAFSEL = 0x73, GPIOPCTL = 0x4883311

It was set up with:

    GPIOPinTypeCAN  (GPIO_PORTB_BASE, PB_Can2Rx_BIT | PB_Can2Tx_BIT );
    GPIOPinConfigure(GPIO_PB4_CAN0RX);
    GPIOPinConfigure(GPIO_PB5_CAN0TX);

I would think that since I put the CAN into test mode and set the CANTST to drive the pin low and high successfully that the pins must be configured correctly.

 Backlight v2.pdf

Code for CAN.zip

Note on the schematic: the inverters U13 and U16 are not installed and Solder Jumpers SJ1, SJ6, SJ7 and SJ10 are jumpered.

Thanks, Doug

BTW, in monitor.cc I'm doing test via SpecialTest() which is down in the "T" section of the code.

Just to make sure when doing this do you run the CANTest function before hand? You need to clear the CANTEST register after doing the loopback mode test.

Could you send a list of commands you use before hand as this seems to be integrated into a UART terminal and I want to make sure non of the previous register configurations are messing with the transmission

Also the Schematic looks good

Hi.  The board was always reset after running CANTest().  Not sure what you mean "commands you use before hand", before what?  Also, "this seems to be integrated into a UART terminal", what does that mean?  There are 2 uarts in use, one for a debug terminal and one for a bluetooth transceiver.  The CAN has nothing to do with them, I'll send you all the code.

Backlight SW 121125.zip

Is it possible that I might have somehow bricked part of the CAM circuitry in the MPU?

I ran the tests on a different board with the same results, so it's not a bad MPU.  Erik, are you still there?

Thanks, Doug

More grist for the mill - I'm not receiving any externally generated CAN messages either.

Again, this issue is Not Resolved !

Hi Doug,

Sorry I was trying to get an understanding of how the flow of your project works. from the code base there seems to be a lot of other tasks outside of intializing the CAN IP that could cause some issues.

On your side are you able to test just running the Cantest() function before the dispatch one in the "main" function? 

What do you mean by "I'm not receiving any externally generated CAN messages either".

I can try running Cantest() without the dispatcher (good idea) .  Re your last question, I have a Pibiger PU2CANFD-C that I set to send CAN messages using Savvy CAN, and no interrupts are generated.

Re "the flow of my project", the Dispatcher is just the "one big process loop", but instead of serially calling all processes to see if they need to run, it's a central place to only run them when they have something to do, so I know when I can put the CPU to sleep.  When an interrupt happens that needs to be processed outside the ISR, it either sends a message to a task ( via ISR_Send_Message() which wakes up the dispatcher ) or sends an Event to a State Machine ( via ISR_Send_Event() - which uses ISR_Send_Message() to  send a message to the Event dispatcher ), thus running is serialized and the ISR messages are synchronized (vastly reduces the chance of race conditions and handling critical sections of code).

I'll let you know how things go.

I copied the code from SpecialTest(), cdT1 in monitor.cc, to right before the call to Dispatch() in main() and no luck.

Hi Erik,

I'm in the process of creating the minimum code to test the CAN bus transmit and I have a question: I'm using the TivaWare CANBitRateSet() function to set the CAN clock rate as used in the simple_tx.c example, but in the Peripheral Driver Library the example uses CANSetBitTiming(), will both work?

BTW, CANSetBitTiming() is mentioned in the tCANBitClkParams documentation, is stated in section 6.2.1 "Detailed Description" that it must be used to set the bit timing, but is not listed int section 6.2 "API Functions" - Functions.

TivaWare 2.1.4.178

Thanks, Doug

OK, I wrote the attached code to eliminate extraneous functions, in main() I call ConfigMPU() followed by CanTest().  

The CAN0TXRQ register is 0x0 before calling CANMessageSet(), right after it is 0x1 - so the message is ready to send, after a delay it is still 0x1, so it never gets sent.

Code attached:

Thanks, Doug

Mmmm, it doesn't like .cc files, I'll try attaching a zip file.Can Test.zip

OK, following what ChatGPT recommended, updated code:

CAN Test 2.zip

Running this results in:

Message not yet set

    CAN0TXRQ1 = 0x0, CANIF1CTL = 0x1

    CAN0ERR   = 0x0, CAN0STS   = 0x0

CANMessageSet() called

    CAN0TXRQ1 = 0x1, CANIF1CTL = 0x1

    CAN0ERR   = 0x0, CAN0STS   = 0x0

After a Delay

    CAN0TXRQ1 = 0x1, CANIF1CTL = 0x1

    CAN0ERR   = 0x0, CAN0STS   = 0x0

Sadly, it doesn't look like it illuminated why the transmission doesn't start.

Sigh ... Doug

I would start with the SDK example as that has been tested and would configure the CAN module correctly. Have you tried the "simple_tx" example in the SDK? This would help narrow down the issue. it also uses the same pins for CAN but you may need to change the UART pins.

Also the TIVAware you are using seems to be outdated could you update to 2.2.0 there may have been fixes between the versions for the CAN module.

I believe both the CANBitTimingSet and CANBitRateSet use the 

Can you try configuring the pin before setting the pin type similar to the SDK example. Below for reference:

GPIOPinConfigure(GPIO_PB4_CAN0RX);

Hello Erik,

I have already tried the "simple_tx" code (if you look earlier in this thread I mention this and downloaded the code),the main() loop runs but the interrupt never happens.

Upgrading to TivaWare 2.2.0.295 did not resolve the problem.

Regards, Doug

Hi Doug,

I sent you an email for further help. we can use this thread if that's preferred.

Earlier in the thread you mentioned using the simple_tx as an example. If the simple_tx is not working there may be some further hardware issues I cannot tell from the schematic. If running the Simple_tx example is causing you issues I am assuming it would be a hardware issue.

For running the simple_tx example please make sure to remove the initconsole if you plan on not using the UART feature to debug the device.

The latest state:  I hired Elco Solutions to take a look at my hardware and software and they sent me the simple_tx code that they successfully ran on their TM4C129 development board, it was almost exactly the simple_tx code I'd already run - they added " CANRetrySet(CAN0_BASE, DISABLE_CAN_AUTO_RETRANSMIT); " which didn't make any difference.  I can only imagine - since the hardware part of the CAN interface is so simple, the the MPU's themselves must be defective.  As such I ordered some new MPU's and will have them installed in my two units and see what happens.

I also ordered a couple of TM4C123G LaunchPads and will run CAN tests on them.

Will let you know what I find.

Regards, Doug

OK, new data.  I used a TM4C123G LaunchPad board and an Adafruit "CAN Pal" CAN bus interface, with the simple_tx example, and still no transmit !!  Here is the code, adapted from a TM4C129 development board, adapted to the LaunchPad.

I see in the TivaWare examples/boards/ek-tm4c123gxl that there is no example for CAN, Are there any examples of CAN being used on a TM4C123 device ?

Doug

Someone needs to look at the operation of this web site; my last post never went through.

Latest news, TM4C123G LaunchPad exhibits same problem !  Code attached.  1) Can anyone show me code that will make the CAN interface work on a Tm4C123 device?  Can anyone make CAN work on a TM4C123G Launchpad?  You don't need a CAN bus driver, just make the CAN Tx pin attempt to send a message.

main.c.zip

Thanks, Doug

P.S., do I get any points for having the longest E2E Thread?

OK, another data point.  I added the attached code to my TM4C1290NCPDT project board - In tracing Can_Test(), it gets to CANMessageSet(...); which returns to the while() delay loop and the CPU faults to FaultISR().  Hopefully I've just made a stupid mistake in the software but I don't see it.

Thanks, Doug

P.S., I did double the stack and heap sizes to make sure that wasn't the problem.