 |
NetBurner 3.5.8
PDF Version |
|
NetBurner 3.5.8
PDF Version |
Example Path: examples/PlatformSpecific/MODRT1171/CAN/CanErrorMonitor
Every CAN controller tracks its own health with two error counters defined by the CAN specification, and this example shows how to read and interpret them on the i.MX RT1171's FlexCAN:
The counters drive the controller's fault-confinement state:
| State | Condition | Behavior |
|---|---|---|
| ERROR ACTIVE | TEC and REC < 128 | Normal operation |
| ERROR PASSIVE | TEC or REC >= 128 | Node keeps working but signals errors passively, so a faulty node cannot disturb bus traffic |
| BUS OFF | TEC > 255 | Node has detached from the bus |
A monitor task samples the counters and fault state once a second and prints a one-line summary whenever something changes:
Everything is read by polling two status registers (the ECR error counters and the ESR1 fault state) – no CAN interrupts are used – so the monitor code is easy to lift into your own application as a periodic health check.
FlexCAN recovers from bus-off automatically: after 128 occurrences of 11 consecutive recessive bits on the bus, the controller re-enters the error-active state and the counters restart at 0. The 'R' menu command additionally shows a full manual re-initialization of the controller.
The FlexCAN driver (fsl_flexcan, NXP SDK version 2.7.1) is built into the NetBurner MODRT1171 platform library; the example includes <fsl_flexcan.h> directly and bundles no driver source.
Same wiring as the CanSimple example: FlexCAN1 RX on module pin P1.26, TX on P1.27 (rev 1.5), to the transceiver's RXD/TXD. Running with no transceiver at all is a supported – and instructive – configuration, described below.
Build and load the application, then open the serial terminal:
The instructive way to run this example is with NO transceiver attached – one 'S' press makes every state the controller can reach play out on its own. With nothing driving the RX pad (the example pulls it up so the line reads as an idle bus), each dominant bit the controller transmits reads back recessive – a bit error – so every transmit attempt raises TEC by 8. TEC races through ERR-PASSIVE (128) into BUS-OFF (above 255) within milliseconds; FlexCAN's automatic bus-off recovery then observes 128 x 11 recessive bit times on the idle line, returns the controller to ERR-ACTIVE with the counters cleared, the still-pending frame retries, and the cycle repeats several times per second. The once-a-second monitor samples this cycle at random points, so the output looks like:
Press 'R' to cancel the retrying frame; the monitor then reports a quiet controller:
With a transceiver attached but no second node, the failure mode changes: transmitted bits read back correctly through the transceiver and only the acknowledgement is missing (an ACK error). TEC climbs by 8 per attempt and parks at 128, ERR-PASSIVE – the CAN specification stops an error-passive transmitter that sees only missing acknowledgements from counting further, so BUS-OFF is not reached in this configuration.
On a working bus (transceiver plus a second node), each acknowledged transmission steps TEC back down, and the monitor reports the return to ERR-ACTIVE as the counters recover.
To verify FlexCAN operation on a single module with no external hardware, run the FlexcanLoopback example first; for interactive send/receive between two nodes, see the CanSimple example.
1.18.0