Using the second CAN (CAN1) peripheral on Tiva C Launchpad

Anyone?

Almost answered yesterday - but these unspecified requirements concern:

a) is this board hack/modification planned to be implemented in some volume?

b) once you "break" the traces between UART/CAN1 and the MCU serving as ICDI - might the input pin of that ICDI MCU still require some, "attention?"  (i.e. pull it high or low)

c) We've made volume (>250 pc) purchase of similar, low-cost, assembled/tested Dev boards.  (M0 - in our case - @ 7 USD we could never approach - even w/our pick/place & reflow oven)  Best to leave that Dev board as much intact as possible - and perform (most always required) signal redirections - proper "bundling" and "add-ons" - upon a 2nd, plug-in board. 

d) Might another CAN module exist - your newly targeted MCU?  Or - might that same CANx port appear upon other MCU pins as well - ones that someway/how "made it" to the board's header?

e) We also use CAN - and find that "co-location" of the required CAN xcvr most always best.  And recall - you likely want the CAN xcvr's I/O to appear @ board header - not the MCU's raw CAN signals.

Hi cb1_mobile,

first of all thank you very much for your comprehensive answer. I'd like to address each point separately:

a) the modified boards will be used as part of a prototype design with a very low unit count (5-10pcs.)

b) that's a good point. Since I think that the UART0 peripheral is muxed to the pins 17 and 18 a pulldown impedance might be necessary.

c, d) the problem is that the CAN1 peripheral of the mounted Tiva C is -only- available on the microcontroller's pins 17 and 18 (and exactly those pins are used for the VCP by muxing the UART0 peripheral)

e) the MCU's CAN0 raw CAN signals are already brought to the Launchpad header. I will design a 2nd plug-in board that connects to the header and mounts a CAN transceiver to actually connect the MCU to a CAN bus.

@ Christian,

Thank you for your detailed, rapid reply - appreciated.

At qty 5-10 - suggest that your "mod" of such board makes most sense.  (should volume reach 50+ I'd vote for custom pcb design)

Might be that "pull-up" is required - see what the "default behavior" of UART TX is - prior to a, "send."  (iirc - UART_TX idles high - then drives low to signal, "Start bit."  ...this from my memory - check...)

Do consider the creation of tiny pcb - to hold CAN xcvr - and supply power and MCU - CAN signals.  Prefer that board to be "attached" to your MCU board - with short, matched length connections, between MCU-CAN signals.  We find many clients "attempt" just as you describe - and too often power up the xcvr w/out the MCU - or connection is dislodged or... Result seldom good/lasting.  (board to board interconnect failure is very high on "list" of field failures)

Wish you well...  (you should be able to find both soic & even DIP CAN xcvr - eases your proto...)

Hi cb1_mobile,

I fully agree with your advices and thoughts. Thank you so much!

I'd only like to have confirmation from some TI Employee that actually worked on the Tiva C Launchpad project to avoid some useless hardware orders and in case begin to search for valid MCU alternatives.

I don't see any problem with cutting the traces to the debug UART connection so long as you cut the right side.  To be perfectly safe you should use a weak pull to ground or tie off the debug UART RX to ground on the ICDI side.  If you were ever did get the ICDI into a boot loader mode then that RX wiggling could trigger the UART ROM bootloader and make it difficult to recover your ICDI.

Upon further review tying it off high is a more correct solution however as long as the UART does not see a 1->0 transition to sense a start bit it should be fine.

Tying UART RX off to its idle state is the correct solution so a pull-up is the correct answer.

Hi Guys,

sorry for my late response, I was very busy these days. Anyhow, thank you so much for your answers, I will pull-up the ICDI's UART RX to maintain it in idle state.