• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 33 subscribers
  • Views 96 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TCAN1044A-Q1: Root causing bit stuffing errors

Desmond Kursinsky
Prodigy 10 points
Part Number: TCAN1044A-Q1

Tool/software:

Hi!

I have a development board for an upcoming product, with intension of using the TCAN1044AVDDFR-Q1 along with a dsPIC33EP microchip (10MHz osc). First hardware bring-up reveals that CAN messages requiring bit stuffing produce errors on the CAN bus, according to my VN1630A.

33ohm resistors are included on the TXD and RXD lines (near the assoc'd driver IC). 

Two 62Ohm resistors originally had a 1nF cap for Csplit (good reworks with SMTs will happen soon, but a hack job with an axial 1nF (or 2) improves CM (from my 3.3V/5V regulator, I presume) on the CANH/CANL). The presence (or the absence) of 100pf caps on the differential signal lines changes nothing obvious. 

UTP wires go to the VN1630A (with the 120ohm attached). I added a ground wire to go between the VN1630A (dsub pin) and the protoboard. No changes were observed. wires/cables are <1m.

I'll try to upload some oscilloscope plots. What sequences should I be looking for? I should be able to get several protoboards' measurements too, if helpful (spoiler, they all seem similar on first inspection).

My software guy can create a simple bit pattern to help me debug, but I'm unsure how to best use this assistance. 

What more can I do to find the source of the error? How do I eliminate my component choices/combinations as the overarching problem? 

Thanks!

Desmond

  • 0
    TI__Guru 50496 points

    Hi Desmond,

    Your approach is solid! I would also recommend confirming TXD is a strong push pull (not open drain) while capturing TXD, CANH, CANL and RXD waveforms similar to figure 7 of https://www.ti.com/lit/an/slyt529/slyt529.pdf?ts=1747126777204 to compare. 

    We are not experts on software (check with the software developer) nor controllers but would recommend to ensure the 10MHz oscillator do not impact CAN bit timing edge if bit rate + timing segment config isn’t tuned by ensuring the controller’s prop, phaseSeg etc are optimal. Further ensure VN is not dominating the bus or includes mismatched timing. 

    You may also use TI’s EVM with the same setup, firmware, dsPIC etc, to rule out component issues, thanks. 

    Best Regards,

    Michael. 

  • 0 in reply to Michael Ikwuyum
    Prodigy 10 points

    Thanks for the reply, Michael. That appnote was one of the leading readings for our approach.

    We think we've resolved/understand our issue.

    For the readers at home - It seems to be a feature of our initialization (and then repeated re-inits at each RTOS tick) of the dsPIC ecan module in the test code. 

    It took looking at macro behaviors (repeated messages and timings, first power on behavior, etc), understanding the code used as our starting point for the bring-up, and CAN packet construction. 

    The HW changes had no effect because they don't appear to be the cause (mark one for the EE's).

    Desmond