CAN simple_tx.c - Only runs in Debug mode on IAR using TM4C123GXL Launchpad

Hello Harry,

When you connect the debugger, w/o downloading the code, what does the NVIC_FAULTSTAT and NVIC_FAULTADDR show the value as?

Regards
Amit

Harry Walton said:

I've created a project and cut-and-pasted the 'simple-tx.c' code into my own file 'project0.c'. I've told the linker where it can find all the various 'can.h', 'uart.c' etc. files it needs and the project builds fine.  

The (always) unjustified/unexplained desire to, "Create a Project" has most likely, "Done you in!"   While you believe you've properly set-up & configured - why expose yourself to that risk?

Instead - your simple, LED-type examples were reported to work when run, "Stand-alone."   Does it not make great sense to simply ADD, "simple_tx.c" to an already tested/verified project?   By your act of, "Project Creation" you've held "simple_tx.c" hostage to all of the demands of the IDE!   (this holds true for IAR as well as the vendor's far lesser & "single vendor only" (ridiculously) restricted version.)

Now my small firm has past used "simple_tx & simple_rx" w/great success - but (again) we employed a proper CAN xcvr. - and communicated w/a "known good" external CAN device.  (we follow (always) KISS which advises strict limitations to the field of battle)   Minus that CAN xcvr your CAN traffic may not fully/properly emerge.   And UART activity provides little insight into CAN performance.

In summary:

• import your chosen can source code into a "Known Working" existing project.  Resist the temptation to "create your own!"
• if not present - procure & implement a proper CAN xcvr so that (real) CAN data may be processed and (hopefully) transferred

Fighting with and mastering your IDE (and all its arcane set-ups & configurations) should be left for "downstream" (or never)...  "Attaching to a known good project has enabled our firm to design/develop & ship quite nicely for past 7 + years..."

Your IDE is simply a, "tool" and may not warrant great investment of time, funds, effort.   Indeed it must work - and that's exactly why both the MCU vendors & IAR provide "Known Good" IDE set-ups - incorporated w/in their, "Factory Approved Projects!"    "Creating your own" places you in a small (likely leaky) boat on high seas - and we (remain) blind to,  "Why you'd, "shove off" when gale winds blow..."

Thanks Amit.

Problem solved - it turns out I had made some basic connection (wiring) errors to my CAN transceiver.

Still, I learnt something new about _FAULTSTAT registers from your suggestion.

Thanks again

Hello Harry

Curiosity: If it was a connection wiring issue, then how did using a debugger make it work!!!

Regards,
Amit

Believe the (delayed) response from unguided posters without, "betting the farm."

Note that (only) the UART transaction was claimed to work, "using Putty I get the expected CAN messages on the UART ("Sending msg: 0x00 ...")"

The debugger's ability to enable success has NOT been explained - and in fact the loss of the UART message - is unlikely to be caused by, "basic connection errors involving the CAN xcvr!"

Hi Amit

A good question! I confess in my excitement at seeing things working, I didn’t give you all information in my short email

In detail –

1. I’d made a wiring mistake

2. I’d also made a mistake inserting the CAN error handler correctly in the interrupt table.

3. I’m powering my external CAN circuitry directly off the Launchpad’s 5V bus pin and Gnd

‘2’ meant that although I was seeing some messages on the UART telling me CAN messages were being sent, the UART wasn’t reporting accompanying CAN-error messages ( the Example Code flow is such that “sending…” UART messages are sent by main(), but “error…” UART messages only appear if you’ve correctly set up the CAN error interrupt handler. I hadn’t.  (It might be gently argued that this possibility for UART “false positives” is a small flaw in the TI Example Code flow, but anyhow…))

O.k., the above explains why I thought CAN was working when it wasn’t, but it doesn’t explain why I had at least some activity in the debugger, but nothing when running “stand alone”. Here, I don’t have a good explanation, only a (speculative) theory related to ‘2’ above :

When using the debugger, I was downloading and hitting “run”, for a fully-powered-up external CAN circuit, connected to my fully-powered-up Launchpad, connected to my PC.

By contrast, when asking the Launchpad to run ‘stand alone’ I was flicking the Lanuchpad ‘on’ switch, meaning it has to power itself up, and provide power-up to the external CAN, before executing code.

CAN buses are a little unusual in requiring things to be at definite (‘recessive’/’dominant’) voltage levels, otherwise errors result. My speculative hunch is that this difference in power-sequencing, combined with wiring error and my failure, to configure the interrupt table properly, led to the difference between debug and standalone.

Ultimately however, I’m not willing to rewire things “wrongly” (and risk Tiva / CAN IC damage) to explore this theory further So, sorry, but we may never know!

Thanks again for the pointers

Hello Harry,

Makes sense now. However I still would like to clarify one point

"I’d also made a mistake inserting the CAN error handler correctly in the interrupt table."
or did you mean
"I’d also made a mistake inserting the CAN error handler IN correctly in the interrupt table."

Regards
Amit