SPRACA7A October   2017  – September 2022 TMS320F28075 , TMS320F28075-Q1 , TMS320F28374D , TMS320F28374S , TMS320F28375D , TMS320F28375S , TMS320F28375S-Q1 , TMS320F28376D , TMS320F28376S , TMS320F28377D , TMS320F28377D-EP , TMS320F28377D-Q1 , TMS320F28377S , TMS320F28377S-Q1 , TMS320F28379D , TMS320F28379D-Q1 , TMS320F28379S

 

  1.   C2000™ Hardware Built-In Self-Test
  2.   Trademarks
  3. 1Introduction
    1. 1.1 HWBIST Overview
      1. 1.1.1 HWBIST Working In-System
    2. 1.2 HWBIST Failure Response
    3. 1.3 Advantages of Using HWBIST In-System
  4. 2Using HWBIST In-System
    1. 2.1 Fundamental HWBIST Operation
      1. 2.1.1 Initializing the HWBIST Controller
      2. 2.1.2 Executing HWBIST
        1. 2.1.2.1 Executing HWBIST Micro-Run
        2. 2.1.2.2 Executing HWBIST Full-Run
      3. 2.1.3 Error Management
    2. 2.2 Managing HWBIST on Dual-Core Device
      1. 2.2.1 Semaphore Management
      2. 2.2.2 Interprocessor Communications
    3. 2.3 System Considerations When Using HWBIST
      1. 2.3.1 Interrupt Latency
      2. 2.3.2 Power Considerations
      3. 2.3.3 HWBIST Memory Requirements
      4. 2.3.4 Injecting Errors
    4. 2.4 Debugging HWBIST In-System
  5. 3References
  6. 4Revision History

2.4 Debugging HWBIST In-System

While the HWBIST micro-run is executing, the emulation connection to the targeted CPU is, for all practical purposes, gone from the system. This means features like breakpoints, watch points, single stepping, or even running are not available for debugging the system code. This comes from the following two aspects of the HWBIST operation:

  • Like the CPU, the emulation analysis circuitry is being scanned so the breakpoint (and other emulation analysis features) is managed by latches that are actively being corrupted by the HWBIST controller.
  • The context of the analysis circuitry cannot be saved and restored.

TI recommends that you do not leave software breakpoints enabled in the code while executing the HWBIST. For this reason, it is necessary to disable the HWBIST operations while debugging the system code. While validating or debugging the HWBIST operations, the CPU code execution must be started using the Free Run operation. If running a dual-core device, then both CPUs must be started using the Free Run operation. When running HWBIST on a CPU, it is recommended to remove any association with cross-triggers (if any are set) for that particular CPU.

Some helping hints for debugging the HWBIST code follow:

  • Use observable points on the board to monitor progress during execution. For example, use one or more GPIO pins tied to a scope or tied to LEDs.
  • You can place loops in the code to "halt" it in place of breakpoints and track its progress.
  • Store debug and progression updates or statuses in the SRAM:
    • Ideally, this is in a range of memory that is not initialized by either the BootROM or the Emulator GEL script.
    • If on a dual-core device, it is good to store these updates in a memory that both CPUs can access:
      • For example, shared memory, IPC registers, or message RAM.
      • The CPU that is not running the HWBIST may be able to halt cleanly and display the debug and progression information.
  • Sometimes after running the HWBIST the emulator Halt operation invokes the following pop-up message:

    Trouble Halting Target CPU: (Error -1156 @ 0x0). Device may be operating in low-power mode. Do you want to bring it out of this mode? (Emulation package 5.1.636.0).

    This message is normal and caused by the emulator losing sync with the processor. The emulator always loses sync, but sometimes regains sync without the aid of this operation. This has nothing to do with low-power mode.

    • If this happens, click the Yes button.
    • If this does not work, then the CPU can be disconnected and reconnected to regain control. On a dual-core device, it is possible that the other CPU is still accessible. Therefore, if debug and progression values have been saved, then the other CPU can provide access to them.
  • If the CPU comes back, but it vectors into the BootROM or flash, one possible reason is that the PIE is not enabled. HWBIST executes a CPU reset upon completion, but if PIE is not enabled, then the CPU vectors to the BootROM instead of the Diagnostic Library STL_HWBIST_restoreContext() code.