The selected device has a non volatile fault log, either manually stored by the user or automatically stored at the time of a fault that disabled an output.
Possible Causes:
- A root level fault (with a non-ignore fault response) disabled a channel on this chip and recorded a fault log
- This device responded to a shared FAULTB pin by disabling one or more outputs and recorded a fault log
- The user manually stored a 'snapshot' of telemetry data into the fault log via I2C
Tips
Typically it's easier to debug a system if power has not yet been removed. For instance, during board development, you can power the ICs from the dongle (and optionally DC2086A for many devices). When a problem occurs, it's easy to use the latched status registers to debug faults very quickly. Otherwise, if power has been removed since the problem occurred, you can use the non volatile fault log for debugging.
- If power has not yet been removed from the devices, and one or more outputs are OFF, use the Why am I Off? tool to quickly understand why a selected channel is off
- If power has not yet been removed from the devices, scan the system for faults stored in latched registers:
- Select the FAULT_WARN_LIST pseudo-register in the Telemetry/Status view
- Use the 'All Pages in System' view to scan the entire system for potentially interesting faults.
- If power has been removed, click the Fault Log button in the toolbar and read the fault log into the GUI for further analysis:
Other Debugging Tips
If you have an oscilloscope, perhaps the fastest way to insight is to:
- Inspect the registers and the fault log for channels/signals of interest)
- Trigger the scope on the falling edge of the ALERTB signal, and
- Probe other signals of interest (preferably at the pins of the IC), and
The ALERTB signal will be pulled low by the IC at the time of the fault, indicating the time of the fault.
