Manual Setup
Communications Ordered Halting Unordered Halting Software Breakpoints Hardware Breakpoints Application IO Restarting Sessions Swappable Partitions Multi-core devicesManual Debugging Setup
You can debug any Hex file without any preparation. However, in this case you cannot specify the entry point - the first halt will happen at or shortly after the reset vector. Neither will you be able to use software breakpoints.
On some of the target devices, debugger needs dedicated resources - flash and data memory. Such resources must be allocated. When using assisted debugging the required resources are allocated automatically. Otherwise, you need to allocate them manually and pass the addresses of allocated resources to the debugger.
Does the target require debugging resources?
You can create the MCU object for the target device. It provides functions which return the amount of necessary RAM and ROM. If the values are zero, no allocation is required.
Alternatively, you can look up the files used for assisted debugging to see if allocation is required for your target device.
ROM allocation
ROM is necessary for debugging executive. Some target devices may have special requirements.
PIC18 - the allocated ROM must be 32-byte aligned
PIC32 - the allocated ROM must be 4-byte aligned
RAM allocation
RAM is necessary for storing the device context during halts and during multi-stepping. Some target devices may have special requirements.
PIC12/PIC16 - the allocated RAM must be in banked memory (not in linear memory).
PIC24/dsPIC33 - RAM allocation is not required because the debugger uses stack, but the stack must be set up and W15 register must point to the stack. This requirement is automatically met for programs written in C, but may not be the case with assembler programs.
PIC32 - the allocated RAM must be 4-byte aligned and must be at or above 0xa0000800.
Clock frequency considerations
NSDSP debugger needs to know the CPU clock frequency. When you program for debug, you need to specify TCY - the period of the instruction clock. If the period you specify is too far off, the debugger may not work. Therefore, you need to know the TCY.
Since with manual setup the first halt happens shortly after reset, you must specify the TCY based on the initial configuration of the CPU oscillator. If the oscillator settings are switched as a part of target device startup, the TCY will change. If it is substantially different from the original TCY, the debugging may not work. In such situations, the only solution is to use assisted debugging and locate the initial entry point after the clock switch.
Debugging
To debug the project with NSDSP Interface library, you need to load the HEX file, specify RAM and ROM addresses (if needed) and program it for debug (which is different from regular programming). The pseudo-code for debugging session may look like this:
hexMap.read("your_hex_file.hex")
NSDSP.create(serial)
NSDSP.setDebugROM(ROMAddress) // If necessary
NSDSP.setDebugRAM(RAMAddress) // If necessary
Session = NSDSP.startProgSession(mcu, readOnly = false)
Session.checkId(adjustRate = true)
debugSession = Session.programForDebug(hexMap, tcy)
// Debugging here
NSDSP.endSession
NSDSP.free
© 2007-2025 Northern Software Inc. All Rights Reserved.