LAUNCHXL-F2800157: Analyzing Error Handling During Firmware Updates via DCAN Flash Programmer Utility on F2800157

Hi Taif,

On the CAN protocol test that you are doing are you deliberately injecting errors to the CAN frames sent to LAUNCH-F2800157 while running the DCAN flash kernel?  How is the error injection done?  Have you tried checking our application note on CAN error injection? 

SPRACQ3 (Configurable Error Generator for Controller Area Network) describes how DCAN frame is generated and how error is injection can be configured in any section of the CAN frame.  One of the methods that this is accomplished is through bit manipulation with GPIO upon locating the desired bit position where error is injected.  Error can be injected (bit flip) in the arbitration, control, payload and CRC section. It can also generate CAN frames without bit stuffing.  The GPIO method is the most straightforward one and this can be done with another launchpad with a GPIO that would directly drive the CAN frame in the LAUNCH-F2800157 under test or using the LAUNCH-F2800157 itself in loopback mode to receive the modified CAN frame with injected errors.

The DCAN in all of the C2000 devices have register CAN_ES (CAN error status register) and contains the field LEC (Last Error Code).  Inspecting this register content after error injection would report the error which can be in the form of stuff, form, ACK, bit1, bit0 or CRC.  A corresponding error increments the error counter and CAN protocol will take action when the error threshold is met.  This is also described in the application note and how the injected errors affect the LEC status depending on the error injected.  Tis conforms with the CAN protocol error handling.

As far as retransmission goes CAN protocol will automatically re transmit frames that have lost arbitration or have been disturbed  by errors or have not received any ACK.  This is true as long as automatic retransmission is not disabled by setting the DAR bit in CAN control register.  By default automatic retransmission is enabled.

Lastly, CAN communication is very robust in that it is tolerant to electrical noise the fact that it uses differential bus lines (CANL/CANH) that cancel out common mode noise.  It also checks for data integrity that uses the built in CRC (15-bit polynomial) routine in the CAN protocol and automatically calculated and added as part of the transmitted frame.  CAN protocol also automatically introduces stuff bits wherein it adds a bit that is opposite the state of the last bit where there are at least 5 consecutive bits of the same state to ensure that there is continuity in the transmitted frame.

To ensure proper CAN bus operation, the CAN nodes need to be terminated with a 120-ohm impedance to minimize reflection.  CAN is also sensitive to timing so ensure that the CAN clock source is stable (see app notes SPRAC35 for bit timing and tolerances as well as app note SPRACE5 under Debug Checklist for Physical Layer Issues and Hardware debug tips).

Best regards,

Joseph