• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 31 subscribers
  • Views 537 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.

Testing for CAN peripheral errors

John Osen
Genius 3585 points


I have written a driver for TiVa's CAN peripheral.  It has been working quite well.   I am now looking at code that is supposed to capture bus errors, such as CRC errors or bit 0 and 1 errors.

The code looks great.  How do I test it?  Every bit of CAN equipment I have does not have the option of inserting bad CRCs or bit stuffing incorrectly or messing up dominant/recessive bits.

Does anybody know of CAN test equipment that can drive such bus failure tests?

  • 0
    Guru 27665 points

    I am (was) working through some of the same issues in order to test bus recovery. 

     

    I was re-directed to other needs for a while and I'm just getting back to it.  I've just finished unit testing (on a PC) the recovery code.  I now need to move to the actual hardware again and attempt testing.

    See previous discussion http://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/t/296961.aspx

    My first though on CB1's suggestion was "why didn't I think of that"

    It won't introduce bad bits but it should allow moving to passive state.  Shorting the bus should get you to an error state.  Not very subtle but it does introduce bad bits.  You could also try coupling errors into the cable. Perhaps on a weakly terminated bus?

    I haven't found anything that would let you introduce errors surgically though.

    Robert

  • 0 in reply to Robert Adsett
    Guru 117855 points

    Alarm bells toggling - subtle may not pass, "KISS first" - thus bus short suggestion.

    Re: CRC - should that calculation be made outside & prior to the CRC's function transmission - cannot you first read - then alter - and send that altered version?

    Otherwise - we've employed a 2nd MCU to "monitor" both CAN and other serial transaction sequences - and this MCU may "flip," drive high, or drive low - any prescribed bit(s).  That 2nd MCU is closely located, closely coupled - and powered by the same source as the "real" MCU.  (some extra "gating" may be required - depending upon circumstance & precision of requirement)

    Not suited for space, human implantation - but quick/dirty and may (to some degree) answer your requirement.  Although "surgical error insertion" would appear "bit of a reach" price/effort/time to achieve is surely right!

  • 0 in reply to cb1_mobile
    Genius 3585 points

    cb1_mobile said:
    CRC - should that calculation

    ...

    I believe the CRC is taken care of in silicon.

    Shorting should prove that the bit1 or 0 error portion of my code works.  Maybe I have to settle for that.

    The 2nd MCU suggestion is a real project? Correct?  It is not a simple task.  I was thinking of just taking the LM4F EKS that I have lashed up to a CAN transceiver, and then, rather than letting the CAN peripheral do all the work, monitor the lines.  But that means implementing what is done in the CAN HW in SW.  I betcha that would take weeks.  Hats of to those that have done it.  I have no time.  So if there is not a tool that is off the shelf, shorting the CAN bus is about all I have time for.

    Thanks for putting thought into it.

  • 0 in reply to John Osen
    Guru 117855 points

    John Osen said:
    The 2nd MCU suggestion is a real project? Correct?  It is not a simple task.

    As past (presidentially advised) depends upon what, "is" (or simple) is...

    We interposed a logic gate between CAN Xcvr &, "main CAN_RX MCU input."  This gate then allowed the flip, tie-low,  or tie-high of the signal "felt" @ CAN_RX.  Gate was controlled by 2nd MCU - which (simply) monitored the CAN bus (via one gpio - as input) - counting the "known" bus transitions - and further (via 2nd gpio - as output) drove the gate @ the correct time/place in the CAN sequence.  (indeed - we first generated & charted the correct CAN sequence for that particular CAN transfer - so that we could add our "modulation.")

    Your specification some(way/how) did not fully include - nor precisely define - the requirement for, "simplicity and/or rush!"  (although method described herein - may so (wrt complexity) qualify...)