Debugging on the Ultra96

Hello,

So I've got all the pieces for my design built, bitstream from from Vivado, a Linux image from petalinux for the APUs and a freeRTOS app for RPU0. However, I'm not clear on how to get it all booted, running and then connecting the debugger to the R5. What I want to do is boot the APUs and load the PL from the SD card. After that, I want to load and debug the R5 via JTAG. However, since the dip switches are set to boot from SD this seem to indicate i can't switch them after booting to boot the R5 from jtag. I haven't tried this yet so I'm curious if this would work.

Or can I create a bif file that will also boot the RPU from the BOOT.BIN on a SD card? If the dip switches are set to SD, can I still connect to RPU0 via JTAG after boot for debugging?

thanks,

jeff

Top Replies

Parents

0 clem57 over 6 years ago

Yes you have a dilemma. So how about working on the R5 without the rest. Any place you communicate with other parts, build fake req/reply logic for testing. Once all is working, put back the real parts for the fake ones and continue your project.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 jhane over 6 years ago in reply to clem57

Hi Clem,
That could be one way but really that would have to be a complete act of desperation and really it would only get me part way since in the end I would still need to debug the real system.

Some good new, booting from JTAG and loading from JTAG are different. I can boot the APU and PL from SD and still download the RPU code via JTAG. However, there is only one UART for both the APU and RPU and only one should be driving it. And for a Wifi only system like the Ultra96 not having a serial console to the APU is not good. Have also discovered that connect the debugger to RPU0 via the SDK seem to bring brick APU0, so the linux side is then dead.

This seems like a pretty common use case so I'm not sure why this seems such a pain to get working and other than the single UART I don't think this is Ultra96 specific.

thanks,
jeff
Cancel
Vote Up +1 Vote Down

Sign in to reply

Verify Answer

Cancel
0 bhfletcher over 6 years ago in reply to jhane

There is a bit of information over on the Xilinx forums for debugging the R5
https://forums.xilinx.com/t5/OpenAMP/JTAG-debug-of-RPU-r5-code-while-running-petalinux-on-APU/td-p/941473

Bryan
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

Reply

0 bhfletcher over 6 years ago in reply to jhane

There is a bit of information over on the Xilinx forums for debugging the R5
https://forums.xilinx.com/t5/OpenAMP/JTAG-debug-of-RPU-r5-code-while-running-petalinux-on-APU/td-p/941473

Bryan
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

Children

0 jhane over 6 years ago in reply to bhfletcher

Hi Bryan,
Yes, I did eventually find that page and it does explain what is happening. The same thing happen if you connect Vivado to the board after linux has booted.
However, before I found that page I found a different solution that doesn't require modifying the the boot process.

start xsdb and then enter the following commands

connect -url tcp:127.0.0.1:3121
targets -set -filter {name =~ "Cortex-A53 #0"}
configparams -context $::xsdb::curtarget disable-access 1
targets -set -filter {name =~ "Cortex-A53 #1"}
configparams -context $::xsdb::curtarget disable-access 1
targets -set -filter {name =~ "Cortex-A53 #2"}
configparams -context $::xsdb::curtarget disable-access 1
targets -set -filter {name =~ "Cortex-A53 #3"}
configparams -context $::xsdb::curtarget disable-access 1
configparams force-mem-access 1

As long as xsdb is running, jtag access is disable to the APU even across reboots

I'm really surprise this information was not easier to find since this seems like a very common use case.

thanks,
jeff
Cancel
Vote Up +1 Vote Down

Sign in to reply

Verify Answer

Cancel