UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 

ZynqMPSoC PMU Firmware - Debug

Moderator
Moderator
2 0 304

Zynq® MPSoC PMU Firmware - Debug

 

The most basic debug log in the PMU Firmware is provided by defining the XPFW_DEBUG_DETAILED and DEBUG_MODE symbols in the build. These symbols enable the definition of the valid debug types for the XPfw_Printf function from all of the available debug types. Every statement using the function is then printed in the serial output.

Launching the PMU Firmware (see the previous blog entry here) displays additional statements in the serial output that might help us to understand the execution flow.

Usually the pre-built serial logs will be enough to debug the code, but if additional statements are required, the XPfw_printf function can be used to add custom log messages after selecting the appropriate log level.

pmufw_02_001.png

The PMU Firmware core code also provides an additional logging mechanism, and functions that can be used for further debugging. The default configuration does not define PM_LOG_LEVEL so there is no logging enabled, however the symbol can be redefined in the project settings menu to define the appropriate log level.

For example, the below serial output log uses the previous launch configuration that executes the FSBL and the PMU Firmware in the target. The console output shows how the nodes that have not been assigned to any master (disabled peripherals in the Vivado design) have been powered-off once the PMU Firmware gets the configuration object from the FSBL.

pmufw_02_002.png

Using the serial log is a common debugging technique and although it is widely used, it might be not the best approach for some cases (adding additional log statements requires additional compilations). Debugging the code with a debugger provides much more visibility as it allows you to debug through the code while having access to the different symbols and memory during the application execution.

The main issue with debugging the PMU Firmware with the debugger is that as mentioned in (UG1137), the PMU Firmware is built by default with -Os and LTO optimization enabled, which makes the debugging experience quite useless. These options can be removed, but that implies that the code will grow in size and as per Table 10-24 in (UG1137) there is not a lot of space available in the PMU RAM memory to allow for this.

The solution is to minimize the optimization level as much as possible while disabling the serial log options in order to save as much space as possible, without disabling any other functionality within the PMU Firmware.

To get the best debugging experience, compile the PMU Firmware with the -Og level and -finlinefunctions-called-one option as per the below image. If the PMU Firmware requires additional modules to be enabled and there is not enough in the memory for the build, use additional optimization options in the build as documented in the GCC documentation.

pmufw_005.JPG

The above configuration settings allow us to set breakpoints and debug through the PMU Firmware code in a seamless way using the Xilinx System debugger. The following image shows a debug session screenshot with a debug session launched from SDK.

pmufw_006.JPG

Up to now the PMU Firmware has been loaded using the debugger, but sometimes debugging a real boot process might be required (for example, a boot image loading from the SD interface). Xilinx SDK provides a way to launch a debug session configured as "Attach to running target". This allows you to just connect to a target and run a custom script.

When debugging the boot process with the PMU Firmware, there are some important considerations that can that make the debug process more complex than with other use cases, but with the help of a script it can be automated, providing a seamless debug experience.

On the one hand, the PMU processor is not accessible from the TAP by default; a gate prevents the access so this needs to be enabled by writing to the corresponding register within the PS.

On the other hand the debug symbol file cannot be mapped before the PMU Firmware is loaded in the device, which means the debugger needs to detect this event to map the file afterwards.

As an example, let's see how to debug a boot image placed in an SD card that has been created using the following BIF file.

//arch = zynqmp; split = false; format = BIN
the_ROM_image:
{
    [bootloader, destination_cpu = a53-0]C:\workspace\fsbl\Debug\fsbl.elf
    [destination_cpu = pmu]C:\workspace\pmufw\Debug\pmufw.elf
    [destination_device = pl]Z:\BSP\2018.3\petalinux-zcu102\pre-built\linux\images\system.bit

}

XSDB script:

#Connect to the target
connect

#Disable Security gates to view PMU MB target
targets -set -filter {name =~ "PSU"}

#Reset system
rst -system
after 1000

#By default, JTAGsecurity gates are enabled
#This disables security gates for DAP, PLTAP and PMU.
mwr 0xffca0038 0x1ff
after 500

#Run the FSBL as XSDB catches the reset vector
targets -set -filter {name =~ "*A53 #0*"}
con

#Run until FSBL loads the PMUFW
mask_poll 0xffd80000 0x10 0x10

#At this stage the PMUFW is loaded and we can place breakpoints
#Load and run PMU FW
targets -set -filter {name =~ "MicroBlaze PMU"}
memmap -file C:/workspace/pmufw/Debug/pmufw.elf

#Set breakpoints
bpremove -a
bpadd -addr &PmConfigLoadObject
bpadd -addr &LegacyEventHandler

pmufw_008.JPG

When the debug configuration is launched on a running target, the device has already been booted, so the first step required to debug the boot process is to reset the system. The system reset triggers the BootROM code again, but this time the debugger catches the A53 processor going to the reset vector as part of the boot process when the CBR loads the FSBL.

As mentioned previously, the PMU processor is not available to the debugger (the MicroBlaze™ processor is not shown under the PMU context) as the gating has been disabled on the system reset.

#Connect to the target
connect

#Disable Security gates to view PMU MB target
targets -set -filter {name =~ "PSU"}

#Reset system
rst -system
after 1000

pmufw_009.JPG

In order to enable the PMU gate, the appropriate register is configured so that the MicroBlaze PMU processor will appear in the debug window. The processor is in a deep sleep state as the PMU ROM code is in service mode and there is no firmware loaded yet.

#By default, JTAGsecurity gates are enabled
#This disables security gates for DAP, PLTAP and PMU.
mwr 0xffca0038 0x1ff
after 500

pmufw_010.JPG

The PMU Firmware debug symbol cannot be loaded into the target until the firmware is loaded in the processor, so the debugger needs to monitor the target to detect this event.

The software indicates that the firmware has been loaded into the PMU through a flag bit within the GLOBAL_CNTRL register in the PMU register map, so the following polling instruction has been included in the debug launch script.

#Run until FSBL loads the PMUFW
mask_poll 0xffd80000 0x10 0x10

#The stop is just placed to show the status at this stage, not present in the debug script
stop

pmufw_011.JPG

Finally, in order to debug an application with source code visibility, the symbol file needs to be provided to the debugger. The following commands have been included in the script to map the symbol file and place a couple of breakpoints based on function names.

In addition to these breakpoints, you can also place breakpoints using the source code window or the breakpoint window, but be aware that these need to be placed every debug session (every time a new debug is launched).

#At this stage the PMUFW is loaded and we can place breakpoints
#Load and run PMU FW
targets -set -filter {name =~ "MicroBlaze PMU"}
memmap -file C:/workspace/pmufw/Debug/pmufw.elf

#Set breakpoints
bpremove -a
bpadd -addr &PmConfigLoadObject
bpadd -addr &LegacyEventHandler

pmufw_012.JPG