This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CCS/AM5728: CCS/AM5728: CCS Support for Beagle Bone AI with XDS200

Part Number: AM5728
Other Parts Discussed in Thread: AM5729,

Tool/software: Code Composer Studio

Hi,

I have an Ubuntu LTS setup with CCS10, a Beaglebone AI, and an XDS200 USB debug JTAG pod.

Wanting to get connectivity to the AM5729 PRUs for development purposes.  I don't see board support for the BeagleBone AI, however you promote that heavily on the Sitara pages.

I have tried all the same AM5728/9 processor cores, plus the EVMs, my debugger tries to connect but times out every time.

Am I out of luck?

  • Hi,

    Since I replied to the thread linked above, I was able to source a BeagleBone AI and did some modifications to it in order to connect to an external Debug Probe. Unfortunately, I was never able to get past a connection error and was going to review the modifications but, with the current situation in the world, I lost access to it and therefore can't progress at this time.

    All this to answer you that integration work was progressing but at this moement you are indeed momentarily out of luck.

    I apologize for the inconvenience, 

    Rafael 

     

  • Rafael,

    Thank you for the reply.  I have been messing with this all day, and yes, the connection error (ICE PICK configuration stage) is the showstopper.

    I am not clear as to where the xxx_pru_startup.js script comes into play, if it is before or after this stage of the debug start process.  I have of course the AM335 script for the BBB, and I'm pretty sure that needs to be correct to get the BBAI processor PRU into a known controllable state.  Not knowing what is happening at the phase that it stalls (ICE PICK) is of course frustrating.

    I'll try tomorrow to see if I can make sense of the js file, and see if I can edit it to comply with the BBAI and the AM5279...since I am new to this processor that may be another day of frustration

    This link/tutorial gave me some hope for tomorrow:  http://software-dl.ti.com/public/hpmp/sitara/debug_pru_using_ccs/presentation_html5.html

    Thanks, Jim

  • Jim,

    Again, I am sorry about this troubles. 

    The PRU connection process is somewhat complicated due to the fact they require the .js script because the PRU is a slave core that needs to be brought from reset from the Cortex A15_0 (the master core).

    If you are getting an error coming from the ICEPICK, then this is the very first point of entry for any JTAG signals and therefore the communications will not be established even with the master core, let alone with the PRU. (ICEPICK is a JTAG data router, just like an Ethernet router that redirects data traffic across its ports).

    I checked the BBAI schematics and couldn't see anything that should be necessary in addition to the cJTAG 20-pin connector itself, but I will try to source one board and make the modifications in my home lab. Hopefully I can do this in a timely manner.  

    Regards,

    Rafael

  • Rafael,

    I decided to get a BeagleBone black board to make sure that the "tools" that I have are working, and glad to say, the BBB board debugs just fine with all of my emulator pods besides the JLink, which I guess is not supported for Sitara, which is fine.

    I also noted that the Eclipse IDE link on the product page for Linux support CCS10 was changed to CCS9 as the tool of choice, when I downgraded to that, things were different, but I still cannot talk to the part via the XDS200.  CCS10 is cooler, but I will take "working" over "cooler" any day.

    So good and bad, my physical setup is validated, but still no AM527x.

    I also noted that the processor list supported under CCS9 does not include the AM5279, but it does support the AM5278.  I cannot for the life of me find a way to add that, since I can do main core debugging with the emulator.  I can also use the ARM gdb tool as weii with CCS9, it is nice to use the XDS200 however just in case.

    Hope that you are getting some progress there on this, thanks!

  • Jim,

    I just received the BeagleBone AI here, but I still need to receive the cJTAG header. 

    Regarding the tests you did with the BBBlack, you are on the right track. At least you isolated the issue to the BBAI/XDS200 

    Jim Rhodes1 said:
    I also noted that the processor list supported under CCS9 does not include the AM5279, but it does support the AM5278. 

    You can update your CCS by going to menu Help --> Check for Updates. The AM5729 is part of the Sitara Device support package starting with release 1.4.9. 

    However, from a pure JTAG Debugging standpoint, there is no real difference between the AM5729 and the AM5728. 

    I'll keep you informed on the development of the situation.

    Regards,

    Rafael

  • Rafael,

    Thank you for keeping on this, I have made some progress, and perhaps the issues are related to what I saw on the BBB, which I got the other day and I can successfully debug PRU code using the XDS200.

    The main showstopper for me getting the BBB to work, was that it was running Linux, or even uBoot, and that caused issues with connecting to any core via the JTAG port.  I had to remove the SDCARD, then hold down the BOOT button while powering the unit on.  I also had to use the bbb+pru_startup.js script load and execute at debug run time, all of that, together, got me to a solid, repeatable debug session on the PRU.

    I even now have the BBAI connecting to the emulator, no ICE_PICK issues, sometimes, and I do not know why that works, or does not work.  I cannot also get the core to stop booting (no BOOT button on the AI) so no matter what I do, there is code running on the main core when I try to connect via JTAG.  I actually got the full listing of the JTAG tree, all cores, once after starting up the pod, but I could not connect to any of them to try to run code via the emulator.

    And now somehow, on that project, CCS9 dies at that point, so I do not even know really what is happening.

    Bottom line, BBB is working for me, repeatable, however I have to keep it from BOOTing.  I see too many "how to" methods on the TI site where we use a GEL, we don't, we use a .js, we can let the processor boot into Linux, we cannot let that boot into Linux, just really confusing the entire issue.

    2nd bottom line, BBAI is closer, the JTAG steering engine is now being identified, but I either crash CCS0, or just don't connect at all.

    My goal, maybe never to achieve:  use the XDS200 to debug code, while the Linux kernel is running.  Perhaps the method is to do all of my PRU code (I need them all in the AM5279 for a highly deterministic application) and then use RPMsg to send up results to may main core while using gdb and either CCS9 or even VisualStudio for Windows, to do the main application.

    Any help, is help, thanks!

  • Rafael,

    Good news on getting your AI, let me know how the debugging goes.  I have progressed quite a distance, I have the PRUs operational and a main core app running, all talking.  So at least I am moving forward.

    I did get the XDS200 in debug mode, but I had to not allow the kernel to boot.  I had no other code running, and I was able to step through PRU code.

    My debugging method is a UART, and pins and a logic analyzer, so at least I can get PRU work done.  The XDS200 would of course be the best method.

    Goal is to be able to debug while in kernel mode, perhaps that is a stretch.  Let me know how it goes, thank you.

    Thanks, Jim

  • Jim,

    I am glad you were able to move forward a bit. I am having a bit of a hard time as I keep getting error -233 that is related to the hardware connections between the JTAG connector (P2) and the device, but I couldn't yet find where the lines are crossed. 

    I would expect to halt the boot process before trying to connect - it is very common that the kernel powers down the debug subsystem and therefore cuts the connection. Usually we workaround this by re-building the kernel and enabling some kernel hacking features - something similar to what I documented a few years ago at:

    https://processors.wiki.ti.com/index.php/Linux_Debug_in_CCSv5

    I tried to simply create a micro-SD card with a separate distro and found out that all my micro-SD cards larger than 4GB are failing to write data properly (I need to go to the nearest store and get a few 8GB+ cards). Oh well... All this would be easier to accomplish if it weren't for the quarantine restrictions, but that is what is my current status. Sorry about the lack of progress. 

    Regards,

    Rafael

  • Hi,

    Ok, I just found out my brand new board is Rev A1, which requires a mod to allow JTAG to operate...

    https://github.com/beagleboard/beaglebone-ai/issues/21

    (it will be soldering time this afternoon)

    Regards,

    Rafael

  • Jim,

    I was finally able to connect following the procedure shown in the link above. 

    Several kinks had to be corrected on the procedure before I was able to properly get a working board, so I will try to update the reference above. 

    One issue that I had and it was causing a connection problem was a ground loop between the board supply (a Samsung cellphone charger) and the FTDI serial cable and the Debug Probe (both connected to my laptop being powered by its own power supply). At a certain point when I connected the serial cable, the Debug Probe started to fail complaining about power supply issues on the board and the serial data was coming through but slightly garbled (a few characters missing or wrong). Knowing this from other scenarios, I plugged the power cable to the laptop and everything became stable again.

    After all this, I was able to properly connect to the board either at the u-boot prompt or when running Linux - the kernel seems to be configured to keep the Debug Subsystem fully powered, which is great news.

    I didn't try to connect to the PRUs but, since you are able to fully connect, this should be alright on my end as well.  

    Hope this helps,

    Rafael

  • Rafael,

    This is amazing!  I will be soldering tomorrow!  Thank you...

  • Rafael,

    Is the blue wire tied to the resistor that was on the two pads, you lifted that, tacked it to the one pad, and the other side to the blue wire?  Move that to a series resistor to the JTAG port?  And same resistor?

  • Jim,

    Before you start desoldering/soldering, can you confirm your board is rev A1 or A2? If A2, then no modifications are necessary. 

    One additional detail: were you ever able to connect to any core via the XDS200 Debug Probe? Somehow I have the impression you were able to connect by halting u-boot. Can you confirm that? If so, then no hardware modifications are required since the absence of these wires prevents any connection to any core to happen. If you are able to connect to one core (either PRU or A15), then the issue is somewhere else. 

    If all these conditions are false, then the rework will be necessary. 

    I followed the method shown by the user sgturner on the github thread but with the following changes.

    As recommended by the section Non-buffered JTAG Signal Termination of the XDS Target Connection Design, I moved the 22Ω termination resistor (R200) of the TCK signal to be close to the emulation header, while I left the 22 (R199) of the RTCK as near the device as possible. 

    The pads further away from the SD Card connector (J90) are the ones connected to the device's pins. The other two pads are simply shorted and are not used. 

    Also, I cut the connection between pins 9 (RTCK) and 11 (TCK) of the emulation header by using a small exacto knife between the pads of the header. Only a small cut is necessary, as the connection is on the bottom layer. Be careful to not cut too deep as there may be other tracks on inner layers (I didn't verify this). 

    Hope this helps,

    Rafael

  • Rafael,

    All three of my boards are A1.

    I managed to use the BBBlack to test out the XDS200, to eliminate that was bad.  The XDS100 also worked there.  I was incorrect in stating that I had no issues with the AI, I never got that to connect.

    Got all of this, I do rework all the time, we have a great lab here.  I will let you know what I find out, probably not until the weekend. I am now trying to battle the PinMux output, to creating a .dts file so that I can get all of my pins working.  I have to get past this, this week.

    Thanks again for the follow-up, it matters.

  • Thanks, I updated the Github thread as well, so it gets more traction for future developers. 

    Good luck with your mods. 

    Cheers,

    Rafael