JTAG Debugging - 2 Code Composers on the Same Machine - One under Ubuntu - The Other under Windows

[Jeff Andich]

Hi,

We're not yet able to setup Ubuntu native on PC's at work, so we're using Ubuntu under VBOX.

I'm attempting to do JTAG debugging via CCS 7.2 to the BB-X15/am572xEVM, but when I run CCS in debug mode under an Ubuntu/VirtualBox, CCS hangs.  I'm able to view registers on the A15_0 core, but I haven't been able to successfully load u-boot-spl.bin built in CCS on Ubuntu.  When I load, CCS never comes back, and I haven't been able to specify the "load address" for the SPL.  From what I understand from reading an older version of TI's CCS wiki, JTAG debugging doesn't work well through a virtual machine.

So I'm trying a strange approach:  2, CCS 7.2 installations on the same machine, 1 under the Ubuntu VM to build the SPL in Linux and another under Windows to manage the JTAG debugging process (e.g. load u-boot-spl.bin via JTAG, view memory, step, etc).  But I'm having some issues using a Windows/VBOX shared folder to contain the u-boot tree so that both the Windows and Ubuntu CCS's can look at the same tree/project.

Has anyone on this forum successfully tried this kind of thing before or are there obvious reasons why this is a bad idea??  

I think the person in the following thread may have tried something like this??

https://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/117880?tisearch=e2e-quicksearch&keymatch=virtualbox%20shared%20folder

I may post up on TI/E2E, but we're working with the BB-X15 image, not the TI SDK image.  I'll try to annotate this thread with any useful information that's thrown our way.

Thanks!!

Jeff

[William Hermans]

If you're serious about your work. Buy a cheap laptop, and install Ubuntu on it.

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/5f061151-4d0a-4633-b601-767a32a9c47b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Dennis Lee Bieber]

On Wed, 9 Aug 2017 09:39:16 -0700, William Hermans
<yyr...@gmail.com> declaimed the following:

>If you're serious about your work. Buy a cheap laptop, and install Ubuntu
>on it.
>
>On Wed, Aug 9, 2017 at 6:23 AM, Jeff Andich <jeff....@gmail.com> wrote:
>
>> Hi,
>>
>> We're not yet able to setup Ubuntu native on PC's at work, so we're using
>> Ubuntu under VBOX.
>>

I have a suspicion that all "at work" computers must be supplied by IT,
with a corporate standard load of software; use of personally owned
equipment could be a disciplinary event.
--
Wulfraed Dennis Lee Bieber AF6VN
wlf...@ix.netcom.com HTTP://wlfraed.home.netcom.com/

[Jeff Andich]

Trying to get IT to allow me to put Ubuntu native on a corporate PC.  Another guy higher up the food chain told me to just try booting an existing desktop PC with an Ubuntu USB stick... 

Also, someone just loaned me a laptop with Windows 10, and I've got an Ubuntu bash shell up from the Windows Linux Subsystem/Ubuntu bash shell.  Am going to try installing Xming, CCS, the JTAG drivers, and see if Windows 10 will allow CCS to talk to the debug probe and to the target...  This could be worse than the virtual machine idea....

Thanks!  jeff

[Mark Lazarewicz]

Don't you want to load the output generated with debug info not the .bin? I've used a lauterbach emulator to load uboot for source level debugging. You need to point to source tree where you built uboot. If I recall correctly we used a dual boot Ubuntu machine at work. We built in Ubuntu and used CCS in windows and had a mount to a shared partition. At that time uboot debugging was possible in linux but I believe we had the linux drivers for the jtag from either TI or Lauterbach. I think using a virtual machine your gonna have issues

Sent from Yahoo Mail on Android

--

For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.

To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

[Jeff Andich]

Thank you!

Yes, I would think symbols would need to be included to break on functions, but I believe the video I watched (TI board port series modules 6,7) specified to load the bin file after switching CCS into debug mode.. When I get a native linux machine setup, I'll be able to report back. Going to try that tomorrow, but then there's that corporate network thing...

[RaulRa...@outlook.com]

I have experience with various C6x DSP EVM and custom boards, but I've never worked with a Sitara board.

What is driving the need to use Linux in the development/debug workflow? Is it development on the ARM portion, or development on the C6x DSP? Or both?

I recently ordered the Beagleboard x15 (just got a batch at Digikey of the Rev C's get 'em while they're hot), so I'll be tackling a similar situation soon. I was figuring that since CCS can run on Windows it would cover at least the DSP part of development. Then for any Linux part, I could use Visual Studio '17 with the Linux dev/debug support (just need SSH and compiler on target).

I'm not against working in Linux per se, and I definitely don't mind targeting Linux for embedded work, but I have my main dev gear running Windows and I don't want to lug around extra gear.

Raul

 

[Jeff Andich]

Thanks!

Well what's driving Linux on this project is the software team is deploying a .Net application over mono-runtime which will run on the A15 cores.  Our software team can test their .NET application on a workstation, and then on the embedded target.  This is facilitated by the BeagleBoard-X15 image being Debian-based.  

Am trying to get familiar with debugging of SPL, the early stages of u-boot, and any other areas where JTAG could be useful via JTAG for troubleshooting of our custom hardware board where we're doing a Linux board port.

Update - Now Have an Ubuntu native installation - CCS doesn't appear to hang - can connect the target via JTAG and view registers

But haven't yet figured out how to correctly load the SPL, run, and step through it. Also the TI board port series shows CCS 5.? which demonstrates debugging of the SPL via first loading the .bin file using a memory load to the "load address" followed by loading the symbol information.  I haven't yet found the "memory load" option on CCS 7.2.

I will try to bring up the beagle-board-patched 2017.01 u-boot-spl first, and then if that looks like a stumbling block will temporarily move to the TI SDK Linux u-boot so I can ask them questions about this process.

Then I will try to post up any useful progress here if that's desired...

Thanks and FYI,

[Jeff Andich]

Quick Question on the BeagleBoard-X15's which are now available:

On the BB-X15, does the PMIC shutdown after 7 seconds like on TI am572xEVM rev A3?

I'm fighting this right now as I'm attempting to connect CCS7.2 to the A15_0 core using the XDS100v2 emulator.

Thanks!

Jeff

[Gerald Coley]

Yes

 

Gerald

--

For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.

To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/be965fe2-b72d-41b8-9ffc-aa8c9d855108%40googlegroups.com.

[Jeff Andich]

Thanks Gerald!

Does anyone by chance have a copy of AM572x_cortexa15_cpu0_startup.gel or AM572x_cortexa15_cpu1_startup.gel hanging around somewhere??

TI e2e pointed me yesterday in the direction of a wiki (  processors.wiki.ti.com/.../AM572x_GP_EVM_Hardware_Setup) which describes in general how to configure CCS to initialize your target prior to debugging and how to get around the PMIC shutdown issue.  That wiki specifies the use of CCSv6 instead of CCSv7.

One of the setup steps is to attach a set of CCS GEL file initialization scripts to each core on the 572x such that when CCS establishes a connection with the target, it calls each of the GEL files to initialize each of the cores prior to JTAG debugging.  One of the GEL files, I understand, sends an I2C message to the PMIC to leave it on all the time.

Two of the key GEL files, AM572x_cortexa15_cpu0_startup.gel and AM572x_cortexa15_cpu1_startup.gel are missing from all of the CCS versions I have successfully installed (CCS 6.1.3, 6.2, 7.2). However, one version of CCS, 6.1.1 which errors out when I try to install it, claims to contain these GEL files - but the installer doesn't get far enough to unpack the ccsv6 directory so I can see if these files are there.

I am working with TI on this and I understand the CCS team is looking into this, but am wondering if some of the beagleboard community has already gotten around this issue while TI is munching on the problem....

I did find, AM571x_cortexa15_cpu0_startup.gel and I will try to hack that up

Or if there's an easier way to setup the 572xEVM/BeagleBoard-X15 target prior to JTAG debugging of the SPL or something else to consider, I would greatly appreciate it!

Thanks in advance!!

[Mark Lazarewicz]

Historically these are supplied by CCS team I remember for OMAP4 these are always easier gotten within TI than outside.

 keep in mind expecting them too allocate resources that have intimate knowledge with every new SOC test gel and distribute them to customers evaluating one chip purchase not millions isn't gonna happen Quickly

Probally more likely it gets added on a newer CCS version. Hopefully someone has that version installed and sends you the missing  gel files 

Typically you might need to modify these to do real work I know we have gel files that were done internal to debug certain sides of the core and fake out the other side or hold it reset.

Good luck I'd suggest studying whatever you have and understanding the bits they set in the TRM especially if your final target board deviates in the slightest way from the reference design the gel files support

Sent from Yahoo Mail on Android

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/5e61cfb7-2282-4235-8029-df0bce268a45%40googlegroups.com.

[Jeff Andich]

Thank you lazarman!

**update** Apparently the correct GEL files aren't missing!  But the GEL file which gets called when you connect to the A15 cores is different than what's listed below from the ti JTAG wiki. gpevm_am572x.gel for both cores instead of AM572x_cortexa15_cpu0_startup.gel.

I was using the wrong target configuration in CCS7.2. Board or Device: AM5728_RevA.  The TI support rep brought to my attention that I should be using.GPEVM_AM572X_SiRevA,  After the switch, CCS set the core-specific initialization scripts back to defaults, and gpevm_am572x.gel was getting called for both A15_0 and A15_1.

After making this change (and increasing the JTAG clock frequency from a default of 1MHz to 15MHz), the GEL file was getting called when connecting to A15_0, and the PMIC was re-configured to stay powered on via the I2C, and CCS stays connected to the target..

FYI,

Jeff