Actions
Forum Thread Details
  • State Not Answered
  • Replies 6 replies
  • Subscribers 347 subscribers
  • Views 1273 views
  • Users 0 members are here
Related

Debugging on the Ultra96

jhane

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

Parents
  • 0

    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.

  • 0 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

  • 0 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

Reply
  • 0 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

Children
No Data