Debugging options for BBAI64

General Discussion
1

Prior to my experiences with Beaglebones and embedded Linux, my embedded experience has been with single-core microcontrollers (uCs) running RTOSs and JTAG stop-level debugging using special hardware like the E10A for Hitachi processors or the BDI2000/3000 for PPCs.

My embedded experience relative to this has been on the BBW and BBB, and then the products I develop for that also use the AM3352/8. However in that uC, I’ve only used the one Cortex A8 core and then only debugging applications in Linux via GDB server for C applications. I, personally, never was on a project where I had to develop kernel module drivers and thus needed a Lauderbach or kgdb/kdb for single step debugging those, but we did have those expertise in house for the few drivers we’ve had to write.

But even when doing more advanced debugging, we often developed a lot of the code on BBBs where there was a USB-exposed JTAG debugger built onto the board for doing things like this.

However now that I’m working with a BBAI64, I realize this is my first foray into development on a microcontroller (uC) with multiple cores. So do similar built-in debugging options exist or is additional hardware required?

One of the other threads I’ve read here recently make reference to mikroBUS. And I see a black caged connector next to the Ethernet port that is silk-screened as mikroBUS. This was the 1st I’d even heard of this and I had to google-search it just to be confident “mikroBUS” wasn’t a misspelling.

I also see a familiar TAG-Connect pad that is labelled JTAG/J11.

The presence of both of these ports leads me to believe that there isn’t hardware built onto the board for hardware debugging…or if there is, there’s limitations and caveats that demanded the presence of these additional ports.

So then I go into CCS and I see a long-list of debugging hardware listed:

PRU_DebuggingHardwareOptions
PRU_DebuggingHardwareOptions816×688 89 KB

Note this may just be for the PRU since that’s the core I have selected.

Just looking at the names, some can be eliminated as options just because they are listed as 20-pin, but that TAG-Connect pad only has 10-pins. Others can be assumed to be either USB or LAN based. But that’s still quite a list. So…

Which of these are best/intended/expected to be used with the BBAI64 (when doing Cortex-R or PRU development)?

And other than connectivity differences such as LAN vs USB, what are the pros and cons as to why you’d choose one over the other?

And if you use one of these, where did you get it (and for how much)?

Note for code running in the Cortex A72s, I don’t expect to need this. I believe I can continue to do what I’m most familiar with which is debug code running in Linux using typical Linuxy solutions. However when debugging code running on the Cortex R5s or PRUs, these options, I’m guessing, are going to require a traditional JTAG connection.

And IF there’s a hardware debugger included on the BBAI64, what are its capabilities and limitations that compelled the BBAI64 developers to include a JTAG port?

As you can see with all the questions, I’m hoping this thread can be an open ended “what do you use, why, and how happy are you with it” kind of discussion, and less of a “here’s your answer”

Also note, for my immediate purposes, I’m mainly only focused on the A72s and PRUs, with the possibility of messing with the Cortex Rs, if anything to get the MCU R5s to kick-off the PRUs before the A72s have completely booted (I’m hoping that’s possible, still haven’t gotten a clear answer as to whether it is or not).

However I’d love to hear from people that are also using a debugger to develop on the other various hardware offerings such as the C6x/7x DSPs, GPU, and Accelerators.

2

I did find in the PRU Cookbook the section that talks about debugging and the most interesting was the prudebug project that allows you to do typical debugging tasks (read register values, read memory, set breakpoints, single-step, etc). However the project was written for a PRU_ICSS subsystem where there is only PRU0 and PRU1. Has anybody expanded the project to support PRU_ICSSG subsystems that have an RTU0, RTU1, TX0, and TX1?

And this is probably very wishful hoping, but is there any chance this has CCS/Eclipse support so all the various functions this code exposes about the PRU can be displayed in a standard IDE form?

3

Hi @Chris_Grey
Have you had look the CCS - Code Composer Studio ?

4

The screenshot above is from CCS

5

Hi Chris,

Not sure if you saw this post yet:

The referenced HowTO link is a good starting point:

It would be nice to hear from a pro that has used CCS and the XDS560 on the BBAI64. Or even Lauterbach.

I would be very interested in learning more about where you go with this.

Fred

6

Excellent information there. And no I had not come across that. It covers multiple platforms, not just the BBAI64, so here’s the highlights that should give anybody else searching this a sense that it is possible, the equipment involved, where the equipment can be procured, and the cost.

~$40 TIAO JTAG Device
Once you get it, you’ll need to add a solder-blob to the pads to bridge-out a connection:

~$30 TC2050-ARM2010 ARM 20-pin to TC2050 Adapter

~$20 TC2050-CLIP-3PACK Retaining CLIP board for TC2050-NL cables – 3 Pack

~$40 TC2050-IDC-NL 10-Pin No-Legs Cable with Ribbon connector

OpenOCD which mimics gdbserver so gdb can be used on the PC to perform the debugging.

You may also want to ditch your BBAI64’s heat sink for active cooling to get better access to the JTAG pad on the circuit board.

I did not see a link to where you can purchase one of those heatsink-n-fans as a kit.

Once you decide its worth investing in these tools, then go read the TLDR to figure out what to do with them.

What I did not get a sense of is how you tell CCS to use GDB to connect to OpenOCD. Although since its GDB, not a proprietary toolchain, this shouldn’t be difficult to figure out.

And I also didn’t get any sense as to whether this is only useful for debugging the Cortex A, or whether it works just as well for the Cortex R5s and PRUs. My guess is since JTAG is a daisychain, those processors are accessible as different Device IDs, but since the product names specifically call out ARM, I don’t know. More digging to figure that out would be necessary.

7

This post goes into my experience getting it to work with an R5 core:

From the last screen dump in that post, it looks like it only works with the A72 and R5 cores.

The whole Minimal Cortex-R5 example on BBAI-64 thread is worth a read. Lots of debugging info there.

8

I remember last year you have installed a jtag connector on your BBAI64. I don’t have the capabilities here tried several years ago with the BBB and destroyed the board. Do you know where I can purchase a new BBAI64 with jtag installed along with the debugger/cables? Or send my BBAI4 to where I can get it done? Last year I purchased a SK64 Evm so I could get PRU and R5 code working on it and porting over to the BBAI64. I think I had to have Linux or some OS running on the EVM core to get power and clocks running on the R5 and PRU’s. Revisting the SK64EVM and applying that to a JTAG equipped BBAI64.

9

Hi Ken,

Last time we spoke, I had just installed a JTAG connector on a BBB not the BBAI64. I also purchased the SK-AM64B. That was about the time you showed me the power of debugging with CCS…

After I saw what you were doing, I purchased an XDS110 and all the necessary cables and connectors to attach it to the BBAI64 with the hopes of using CCS with the BBAI64. Unfortunately, my time to explore the BBAI64 became constrained, and I had to put that project on hold. I can share the parts list if you would like to see what I bought. Not sure if it will work however, because I never tested it.

Fred

10

I would like the parts list, and if any one knows on this forum where I can get it installed I would appreciate it.

I have just installed the debian image on my SK-AM64B, tisdk-debian-bookworm-a64xx-evm.wic.xz which I downloaded from TI. The goal here is to use the CCS jtag debugger and be able to take that experience over to the BBAI64.

Since I installed “Bookworm” on my BBAI64 I no longer have a need for a Debian 11. My cross compiling for the BBAI4 using Ubuntu 22.04 is compatible. I would recommend 22.04 LTS to you which would put us on the same page.

11

Ken,

There is no need to install anything on the BBAI64 to use the TC2050-IDC-NL JTAG connector. This video at 2:38 shows how the TAG-Connect works.

Here are the parts:

  1. TMDSEMU110-U : TI XDS110 Debug Probe
  2. BH-20e_cTI-20t_ARM : Blackhawk JTAG pin converter
  3. TC2050-ARM2010-M : TagConnect 20pin male to TC2050 adapter
  4. TC2050-IDC-NL : 10-Pin No-Legs Cable with ribbon connector
  5. TC2050-CLIP-3PACK: Retaining clip board for TC2050-NL cables

Like I said earlier, I don’t know if this works with CCS and the BBAI64 but, I expect electrically it should be correct. I did solder blob the TRST on the TC2050-ARM2010-M.

Picture:

XDS110-BBAI64-Setup
XDS110-BBAI64-Setup1920×1440 207 KB

Regards,
Fred

12

Have you plugged this in to your BBAI64. Have you traced the wiring from the XDS110 through schematically, and did a continuity check?

The next step is to launch CCS and create a target configuration. Window → View->Target Configurations
select the New Target Configuration File ICON
which will open a pop up to select the location for the file another view then:
You can use a shared location or not. It may be a future benefit for now I sille unselect
“Use shared location” and select my “Workspace” and then select my Project “SquareWave0”
You can name or rename file later. For me I will use SquareWave0.ccxml.
Select OK and a new file In your source code editor Window.

SquareSave0.ccxml:
Select Connection: Texas Instruments XDS110 USB Debug Probe
Board or Device: J721E_DRA829_TDA4VM – Not sure may work, or try Beaglebone
Save your configuration

Now Test the connection – Assuming that your PC connects via your USB port.

PS: Not sure this will work

13

I haven’t done anything other than buy it. I don’t have any time available to work with it at the present moment. If you want to give it a shot, PM me your shipping address on discord and I will ship it to you on loan for 3 months.

Fred

1 Like
14

Device: J721E_DRA829_TDA4VM should work, you don’t need to treat the AI64 any different from the SK EVM, you’re debugging the processor core after all, anything else is irrelevant as far as the JTAG probe is concerned in CCS.

You shouldn’t need to have an OS booted at all, if anything it’s probably better to have the board in a “no-boot” state where the boot loader is just idling. - At least that’s the case for most Sitara class devices.

I believe CCS should load some initial GEL scripts to kickstart a core when you select it and connect but from memory on doing this on AM64 it might be there’s a sequence where you need to connect to one core or another first… I’m away form my desk so don’t have one handy to try right now.

15

My objective is to work with a running linux image. I am currently working with the SK am64x with a prebuilt linux os. The problem I am currently having is I need to setup a device tree overlay that can set the pins that I need. The devloped apps that I have been working with the non rtos examples and the connecting and loading a r5 to set the clocks, power, and pins for use with the PRU’s. At this point I don’t have a XDS for my BBAI64. When I mastered the SK am64x I will move to the BBAI64.

Thanks for the advice.

16

Maybe you can try to use openocd’s dmem driver to create a gdbserver, so that you can debug R5 core programs without a hardware debugger. The original link is here:

  1. Minimal Cortex-R5 example on BBAI-64 - #21 by Nishanth_Menon
  2. https://review.openocd.org/c/openocd/+/7088/8
17

In addition, if you only need to debug the ARM core on TI’s K3 architecture SoC, in fact, OpenOCD already has relatively complete support. The hardware debugger does not have to be the XDS series. I have tried JLink and DAP-Link and they are both feasible solutions. The only thing to note is that when using a hardware debugger, TC2050-IDC is required. It is used to connect to the Beagle development board. In addition, additional adapters are required to connect XDS, JLink and DAP-Link. For specific support information, please refer to the following file: openocd/tcl/target/ti_k3.cfg at master · openocd-org/openocd · GitHub

18

Thanks. One of my issues is dealing with Kernel upgrades and Device Trees. I have had success with 5.10 with PRU apps. Been able to devlope them on the AM64b-sk and moving them over to the BBAI64 j721e with building Device Trees for the IO. I am currently hung up on trying to move up to kernel 6.6. Seems that the drivers being used and Device Trees are totally different from 5.10.