Guidelines for Developing a Nios II HAL Device Driver

Download PDF
ID 683146
Date 6/12/2015
Public
Document Table of Contents
Document Table of Contents x
1. Guidelines for Developing a Nios II HAL Device Driver
1. Guidelines for Developing a Nios II HAL Device Driver x
1.1. Prerequisites for HAL Device Driver Development 1.2. Developing the HAL UART Device Driver 1.3. Debugging the bit_bang_uart Project 1.4. The BitBangUartTransmit() Function 1.5. The BitBangUartReceive() Function 1.6. Creating Device Hardware Access Macros 1.7. Staging the HAL Device Driver Development 1.8. Understanding the Hardware-Specific INSTANCE and INIT Macros 1.9. Integrating a New HAL Device Driver in the BSP 1.10. Understanding HAL Mutual Exclusion Resources 1.11. Overview of Debugging Tools for HAL Device Drivers 1.12. Debugging the HAL UART Device Driver 1.13. Conclusion 1.14. Document Revision History
1.1. Prerequisites for HAL Device Driver Development x
1.1.1. Using the HAL Architecture and Services 1.1.2. Software Requirements for the Driver Example 1.1.3. HAL Device Drivers and Components
1.2. Developing the HAL UART Device Driver x
1.2.1. Preparing the bit_bang_uart Application and hal_my_uart BSP 1.2.2. Preparing the my_uart_driver Device Driver 1.2.3. Configuring the Altera_Avalon_UART Component 1.2.4. Importing Projects 1.2.5. Verifying Software Functionality 1.2.6. Preview: Customizing the Design
1.2.6. Preview: Customizing the Design x
1.2.6.1. Making Software Modifications 1.2.6.2. Making Hardware Modifications
1.12. Debugging the HAL UART Device Driver x
1.12.1. Setting Breakpoints in the my_uart_driver Device Driver 1.12.2. Setting Watchpoints in the HAL UART Device Driver 1.12.3. Reducing Driver Code and Memory Footprint 1.12.4. Interrupt Latency and Determinism 1.12.5. Debugging with the Altera Logging Functions
1.12.3. Reducing Driver Code and Memory Footprint x
1.12.3.1. Using the Reduced Device Drivers API Option 1.12.3.2. Using the Lightweight Device Drivers API Option
1.12.5. Debugging with the Altera Logging Functions x
1.12.5.1. Altera Logging Usage 1.12.5.2. Altera Logging Example
1. Guidelines for Developing a Nios II HAL Device Driver

1.12.1. Setting Breakpoints in the my_uart_driver Device Driver

This section demonstrates the use of breakpoints to examine HAL device driver activity. Perform the following steps:

  1. After importing the hello_world_my_uart project, open the my_uart_init.c device driver source file, located in the hal_my_uart project, at the following directory:

    <my_design> /software_examples/bsp/hal_my_uart/drivers/src/my_uart_init.c

  2. Place a breakpoint at the top of the function named my_uart_irq(), as shown in the figure below.
  3. Restart Tera Term if it is not already running.
  4. Create a debug configuration for hello_world_my_uart by following the steps 3 through 8 in Debugging the bit_bang_uart Project and substituting the hello_world_my_uart application for the bit_bang_uart application.
  5. Start debugging the hello_world_my_uart application. The processor pauses at the top of function main().
  6. Click the Resume button. The Nios II processor pauses at the my_uart_irq() invocation.
    Figure 20. Setting a Breakpoint on my_uart_irq()
  7. Step up to and over the following assignment of the status register:

    status = IORD_MY_UART_STATUS(base);

  8. In the Variables view, set the format of the status variable to hex. The status register now holds the value 0x60. This value indicates bits 5 and 6 are set. According to the my_uart_driver register description in drivers/inc/my_uart_regs.h, these two bits indicate transmit ready and transmit. The UART driver is in an interrupt context, ready to transmit the first character of the string "Hello from Nios II!".
  9. Continue stepping through the procedure. The my_uart_irq() function invokes my_uart_txirq() in response to a transmit interrupt.

    Press Resume after each character is transmitted. Stop after the entire string “Hello from Nios II!” is transmitted.

  10. Remove the breakpoint.

After you pause the debugger in an ISR, the rest of the system is in an unknown state, because it could not respond to other interrupt requests while paused in the driver. Therefore, you need to start a new debugging session to perform further debugging.

Related Information
Level Two Title