CCS/CODECOMPOSER: PRU debug under Linux

Mark,

It is possible to debug the PRUs while the Linux is running but it's been quite some time that I have done this. I usually debug the PRU but with the Cortex A running bare metal code.  

An overview would be along the following lines: 

The process with Linux should be a bit more simple, given that you don't have to initialize the hardware using CCS (Linux does that for you) and you issue the remoteproc (or pruloader) command. However, you need to change your PRU code to "halt" it at a certain point so you can connect to it and start the step-by-step debugging (otherwise the PRU starts running freely).

At that point you configure CCS for your BeagleBone Black and manually connect to the PRU core. It should be halted at the pre-determined point above. 

Detailed information should be available in the wiki and the TI training sites. I f you haven't checked them, please refer to:

http://processors.wiki.ti.com/index.php/PRU-ICSS  

https://training.ti.com/search-catalog/field_language/EN/categories/processors?keywords=PRU&start%5Bdate%5D=&end%5Bdate%5D= 

Hope this helps,

Rafael

Thanks very much for the reply.  

I will look at this as well.   In my poking around it would seem that there exists the old way of doing things and the new way now which would be the sdk.  I wonder if you could speak to the difference and applicability of this tool compared to the older approach.  It look like it simplifies linux applications that interact with the pru's.  is this true ?  is there an easy migraion of an old project style to the new sdk approach?  when would one do so?  my challenge is I have an old project that I will need to support for some time going forward and am trying to decide the best approach.  original project was done with ccs 6.x

thanks for your help.

Mark

Mark, 

The Processor SDK certainly simplifies the development of PRU applications where Linux is hosted on the main applications core of the AM335x device, but given that I am not entirely familiar with the more modern SDK (as I work for another group), I rely on e2e wisdom to get some pointers. 

There is an over arching document that talks about the migration between the older software development kits and the newer Processor SDKs.

http://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/Release_Specific_Migration_Guide.html 

It talks a lot about the differences in components and other specific aspects such as location of files, etc. This may be useful for you depending on how legacy your projects are. 

Specifically for PRU, depending on the legacy code you have, the thread below may be very useful for you: 

https://e2e.ti.com/support/processors/f/791/t/619971 

At this point I will defer to the expertise of the fine folks at the Processors group for further support. I contacted them to reply to this thread. 

Hope this helps,

Rafael

Hello Mark,

What version of Linux was the ARM side of the project initially developed on? Are you trying to continue to use that version of Linux, or are you trying to migrate to a more recent version of Linux / Processor SDK?

The "new way" of doing things to the PRU from ARM Linux would probably involve loading PRU firmware, running PRU firmware, and (depending on the kind of data transfer desired) communicating between ARM and PRU using RPMsg. I can point to more specific getting started examples depending on what you are looking for.

Regards,

Nick

Hi Nick -  Thanks for joining in the fray.  the original linux version is 3.8 i believe.  ccs 6.2.1 for pru.   Pruss  (not rproc) api.   

The way I see it is I would be best to stay with original versions and make them work, but concerned that the systems may get depricated away and I will be stuck.  I am not super familiar with threaded processes (which this application has a lot of)  so I am also concerned about being able to debug effectively.  currently a logging debug approach has been used I think .  the code is generally stable with no changes to prus for several years and some change on the linux end.  Really just trying to get a handle on the best approach going forward to support ongoing development of the entire system.

Thanks for any thoughts you might have and super appreciate the help.

Cheers

Mark

Hello Mark,

To confirm: Is this the API you are using? PRU Linux Application Loader API Guide. If so, we stopped supporting it several years back. Our current Linux Processor SDKs use RemoteProc to initialize the PRU instead. If you think you will continue using that API, please to the left side of the wiki page screen and select "Download as PDF" now. I cannot promise that wiki page will still be around in 2020 or 2021.

We do not support Linux 3.8 on these forums - at the moment I can answer questions about 4.9, 4.14, and 4.19, but even 4.9 support will get phased out sometime soon.

Linux Processor SDK is basically TI's distribution of Linux packaged with examples, example file systems, etc. It does not have special debug tools that you could not find in anybody else's distribution of Linux. However, it will have the most up-to-date PRU drivers and other Linux code. There might be a delay between when a PRU driver is updated in TI's Linux distribution, and when that update is pushed upstream for other Linux distributions to use.

In terms of debugging Linux / PRU interaction: Rafael is the guy who can comment on connecting debug tools like CCS to Linux & PRU. I typically just use printk messages to debug my Linux code. My primary tool for debugging PRU code is similar (define memory locations, write debug values to those memory locations, use devmem2 to read the values that the PRU has written).

Let me know if you want a more formal list of PRU debugging techniques.

Regards,

Nick

Hi Nick -

That is the driver I am using. Than ks for this , this is hugely valuable information, as we will need to figure out the forward path.  Thanks for that.  Any debugging guidance I can get would be great so if you can list or point me to resources I would appreciate it.

general comment - I am a generally bare metal guy so using an IDE is kind of normal to me.  It seems there is a nother school of prinf (printk) debuggers out there.  can you comment on what that might be? seems to me the IDE shows more info but perhaps not as good for real time muti thread?  Kinda noob in that space.

Thanks

Mark

From post UART Pins Don't work with PRU:

How to inspect a PRU variable value? If using Code Composer Studio (CCS), you can just inspect it there. If using Linux, you can save variable values to a known location by adding test code to your program similar to below.

#define TESTA    (*((volatile unsigned int *)0x100)) 
 
main(void){
              TESTA = 0xDEADBEEF;
}