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: 
Highlighted
Observer pstootman
Observer
7,793 Views
Registered: ‎03-29-2015

Development/JTAG/debug approaches for PS1

Jump to solution

Hi,

 

1) How to debug a baremetal PS1 application using JTAG (ie be able to set breakpoints and step through code on PS1), when using OpenAMP with linux on PS0 ?

I have windows machine and windows SDK so I don't have the petalinux tools on my PC. My colleague has prepared a board which boots linux automatically on power up, and we know the commands to run at the linux command prompt to start up the remoteproc/rpsmsg steps.

I am developing the .elf for PS1.

 

2) If above is not possible, and lets say I set up a linux machine and petalinux so I can do JTAG boot of the linux, even then I'm unsure how to go about debugging of the PS1 program (which is FreeRTOS/OpenAMP), any tips ?

 

3) In short term, for simplicity, I also like to debug the functionality of PS1 program with PS0 running just a simple baremetal program which doesn't do anything much launch PS1 on startup (to verify all the parts of the PS1 program that do not depend on messages between the linux and PS1). i guess this way would be much simpler to load both PS via JTAG, though I'm unsure of the exact SDK steps to do this. Perhaps this PS0 code could also act as openAMP master so I can check the PS1 code that implements the remote side of the openamp. Where could I find example of such PS0 programs?

 

Many thanks.

 

0 Kudos
1 Solution

Accepted Solutions
Observer pstootman
Observer
14,427 Views
Registered: ‎03-29-2015

Re: Development/JTAG/debug approaches for PS1

Jump to solution

To assist others; after much experimentation (I could find no simple guide/doc from Xilinx on how to do what I guess must be a very common need);

I think approach (1) is the easiest way to debug a baremetal PS1 app, with linux on PS0.

Steps;

Physically connect JTAG pod to PCB (and PC :) )

Boot linux on PCB as if JTAG was disconnected (don't use JTAG boot mode, boot from QSPI/SD/MMC/etc as appropriate for your board)

 

In SDK, set up a new 'Debug configuration' of type 'TCF, System Debugger'

Set type as 'Attach to running target'.

Set connection as 'local'

Ignore the rest of the options in the debug configuration for now; SDK doesn't let you associate .elf file yet (for the PS1 symbol info)

 

Launch debug session. SDK will show 2 running ARM processors.

Select AP, then press the pause button on toolbar so that both processors are suspended at same time.

Now select AP - PS1, then right click to add symbol file (browse to the .elf file to be debugged). The selected .elf file now gets saved in the debug configuration, so this only needs to be done once. Not sure why you can't do this step before launching the debug config for the first time... I guess SDK wants to detect what processors exist first.

Now also copy .elf file to be debugged from your PC to the PCB linux file system.

Now, on linux command line, can probe remoteproc to start the .elf running on PS1

 

When adding breakpoints in SDK, just click on bar at left of source file in editor as normal, but then check the scope (under the breakpoint list). If it says 'no scope identified', right click on the breakpoint to set its properties, and under scope, de-select PS0. Also tick 'temporary' under breakpoint type. (If SDK tries to add breakpoint with a scope that includes PS0, you get a 'MMU mapping error' shown at the line where you tried to add breakpoint.

There appears to be some 'default breakpoint scoping rule' you can set, but I can find no information anywhere about the expected syntax, so I just have to manually set the scope for each breakpoint I add.

Build the .elf using -O0 (no optimisation) and -g3 (max debug). I believe the absolute paths to the source files are embedded in the .elf file. So when the PS1 CPU reaches breakpoint address, and PS1 suspends, SDK will automatically find/open the right source file (assuming the .elf was built on the same machine it is being debugged on). Then you can start stepping through the code.

 

Once setup, this workflow seems quite fast => Make some source change, build the .elf in SDK, copy .elf to target filesystem (usually quick if eg over ethernet eg FTP), launch debug session in SDK (very quick since debug configuration already setup, and just attaching to target and not downloading anything via the slow JTAG), remoteproc to launch PS1, and the breakpoints you set before are still remembered in the breakpoint list, so you can add your own breakpoint in main() function if you want to.

I think you need to suspend processor once then restart it (after attaching to running target), to make sure breakpoints get programmed.

 

And its easiest to debug the PS1 application as it sits in the final system, so it can send/receive the actual custom messages you want to move via OpenAMP to your custom linux PS0 applications.

 

Above works with windows SDK, which is handy if you are not into all the details of what is happening on the petalinux/PS0 side.

 

0 Kudos
1 Reply
Observer pstootman
Observer
14,428 Views
Registered: ‎03-29-2015

Re: Development/JTAG/debug approaches for PS1

Jump to solution

To assist others; after much experimentation (I could find no simple guide/doc from Xilinx on how to do what I guess must be a very common need);

I think approach (1) is the easiest way to debug a baremetal PS1 app, with linux on PS0.

Steps;

Physically connect JTAG pod to PCB (and PC :) )

Boot linux on PCB as if JTAG was disconnected (don't use JTAG boot mode, boot from QSPI/SD/MMC/etc as appropriate for your board)

 

In SDK, set up a new 'Debug configuration' of type 'TCF, System Debugger'

Set type as 'Attach to running target'.

Set connection as 'local'

Ignore the rest of the options in the debug configuration for now; SDK doesn't let you associate .elf file yet (for the PS1 symbol info)

 

Launch debug session. SDK will show 2 running ARM processors.

Select AP, then press the pause button on toolbar so that both processors are suspended at same time.

Now select AP - PS1, then right click to add symbol file (browse to the .elf file to be debugged). The selected .elf file now gets saved in the debug configuration, so this only needs to be done once. Not sure why you can't do this step before launching the debug config for the first time... I guess SDK wants to detect what processors exist first.

Now also copy .elf file to be debugged from your PC to the PCB linux file system.

Now, on linux command line, can probe remoteproc to start the .elf running on PS1

 

When adding breakpoints in SDK, just click on bar at left of source file in editor as normal, but then check the scope (under the breakpoint list). If it says 'no scope identified', right click on the breakpoint to set its properties, and under scope, de-select PS0. Also tick 'temporary' under breakpoint type. (If SDK tries to add breakpoint with a scope that includes PS0, you get a 'MMU mapping error' shown at the line where you tried to add breakpoint.

There appears to be some 'default breakpoint scoping rule' you can set, but I can find no information anywhere about the expected syntax, so I just have to manually set the scope for each breakpoint I add.

Build the .elf using -O0 (no optimisation) and -g3 (max debug). I believe the absolute paths to the source files are embedded in the .elf file. So when the PS1 CPU reaches breakpoint address, and PS1 suspends, SDK will automatically find/open the right source file (assuming the .elf was built on the same machine it is being debugged on). Then you can start stepping through the code.

 

Once setup, this workflow seems quite fast => Make some source change, build the .elf in SDK, copy .elf to target filesystem (usually quick if eg over ethernet eg FTP), launch debug session in SDK (very quick since debug configuration already setup, and just attaching to target and not downloading anything via the slow JTAG), remoteproc to launch PS1, and the breakpoints you set before are still remembered in the breakpoint list, so you can add your own breakpoint in main() function if you want to.

I think you need to suspend processor once then restart it (after attaching to running target), to make sure breakpoints get programmed.

 

And its easiest to debug the PS1 application as it sits in the final system, so it can send/receive the actual custom messages you want to move via OpenAMP to your custom linux PS0 applications.

 

Above works with windows SDK, which is handy if you are not into all the details of what is happening on the petalinux/PS0 side.

 

0 Kudos