Guidelines for Developing a Nios II HAL Device Driver

ID 683146
Date 6/12/2015
Public
Document Table of Contents

1.11. Overview of Debugging Tools for HAL Device Drivers

The Nios II EDS and Quartus II software tools provide a variety of mechanisms for debugging device drivers:

  • You can monitor individual component instance signals for activity with the SignalTap™ II logic analyzer. For example, you can hook up the SignalTap II logic analyzer to the UART hardware transmit line to watch for any activity while you write characters to the Altera_Avalon_UART component instance through the my_uart_driver device driver.

For information about using SignalTap II with Nios II systems, refer to AN446: Debugging Nios II Systems with the SignalTap II Embedded Logic Analyzer.

  • You can step into the fprintf() function, stepping through the various layers of abstraction until you reach the HAL’s invocation of my_uart_write() function in the my_uart_driver device driver.
  • You can set breakpoints in the driver’s ISRs, or set watchpoints on UART memory-mapped registers to pause the processor when a character is received.
    Note: Use caution when setting a breakpoint in an ISR. When you resume, there might be problems with other devices, if they generated interrupts that were not handled. However, sometimes the best way to debug a specific device driver is to set a breakpoint in it. When this technique is required, you can reset or download the software containing the device driver again when you are done with a particular debugging session.

These mechanisms can help you diagnose an incorrectly configured system. For example, if the interrupt controller receives a spurious interrupt signal, the interrupt might not be properly handled. When interrupts are enabled after low-level system initialization, there is no way to clear the interrupt source. As a result, the application does not work correctly. The Nios II SBT for Eclipse debugger might even stop communicating with the processor.