File writing from PRU

[Clark Sann]

I need some help from someone who has succeeded in getting the PRU to write files onto the host's file system. I have tried two methods:

1. Using open, fputs, fprintf, etc. This does not work for me. First of all, unless I set the printf_support flag to minimal, even a simple program with only a single print statement uses more instruction memory than the BeagleBone PRU has. Even if I set the flag to minimal, I do not find that any files have been written.

2. Using the low level drivers described starting on page 124 of the PRUC Compiler V21 User Guide. I also cannot get these functions to write a simple file. 

If anyone has succeeded in getting either of these methods to write a simple string to a file, would you please consider posting some sample code?

Clark

[Charles Steinkuehler]

You cannot write to anything like a file directly from the PRU. The
best you could do is enable the PRU UART and craft a version of the C
library that would let you do printf() or similar to a console.

If you need to save data into a file, you will have to pass it from
the PRU to the ARM at which point you can do anything available via
Linux (print to console, write to file, send via Ethernet, etc).

--
Charles Steinkuehler
cha...@steinkuehler.net

[Clark Sann]

Thanks Charles. I agree that it seems to be impossible to write to the ARM file system. I wanted to do it to get better diagnostic information while I am debugging my PRU firmware. I'm finding that turning on outputs when I reach certain sections of firmware is growing tiresome. I might try enabling the UART and using it to send messages to me. 

But why did TI blather on and on about the printf_support switch and the high and low level IO drivers in the PRU C Compiler manual?

What do you do to get diagnostic info while debugging PRU firmware? 

I know of a few methods:

1. Turn an output on or off when a certain section of code is reached. (I do this but is is certainly primitive.)

2. Put a value in a register. Halt the PRU and inspect the registers. (I haven't tried this yet.)

3. Go into an infinite loop when a certain section of code is reached. (This sounds really weird but I think TI actually advised this as a potential debug method.)

4. Buy a JTAG and use CCS. (This is supposed to provide some type of breakpoint.)

5. Enable the PRU UART and send out diagnostic messages. (This seems promising.)

6. Use RPMsg to pass debug strings to the ARM. (This also seems promising.)

Clark

[Charles Steinkuehler]

On 8/8/2017 10:11 AM, Clark Sann wrote:
>
> But why did TI blather on and on about the printf_support switch and the high
> and low level IO drivers in the PRU C Compiler manual?

Because you can get printf working if you add a UART or other means to
get data out of the system.

> What do you do to get diagnostic info while debugging PRU firmware?

My typical methods:

* "Twiddle" pru output pins at various points in the code. Note that
if you've got a good 'scope or logic analyzer (I'm typically using an
Agilent MSO with 16 digital channels), you can shift out data values
with a single pin, so it can be more useful than just "LED" style
debugging.

* Dump data into a chunk of shared memory (typically one of the PRU
data RAMs) and examine it from the ARM side.

* Use a debugger to single-step the PRU code. I typically use the HAL
based one provided with Machinekit but there are now several others
available.

Regardless, debugging on the PRU is much harder than debugging code on
the ARM side.

--
Charles Steinkuehler
cha...@steinkuehler.net

[Clark Sann]

Thanks, Charles, for the great ideas.

I definitely agree with you that debugging on the PRU is hard. I’ve been working on a problem on and off for weeks. I’ve solved it now but had decent debugging tools it would have only taken a few minutes. (Or if I knew C better!) It’s like trying to play tennis with a bag over my head. Lucky for me, I don’t get paid for this stuff.

Today I got RPMsg working. I’m now using it to send commands to the PRU and to retrieve rudimentary diagnostic data. So I hope to pick up the pace a little bit. The PRU certainly has a steep learning curve!

I’ll also look into your suggestions. Thanks again!

Clark

> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/hM0UojPprcY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/e5397db0-ee22-e884-a2d5-893936dea0df%40steinkuehler.net.
> For more options, visit https://groups.google.com/d/optout.

[Mark Lazarewicz]

That sounds like a perfect justification to spend $90 on jtag

Sent from Yahoo Mail on Android

> To unsubscribe from this group and all its topics, send an email to beagleboard+unsub...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/e5397db0-ee22-e884-a2d5-893936dea0df%40steinkuehler.net.
> For more options, visit https://groups.google.com/d/optout.

--
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+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/0F280D4F-A9C9-4A8E-922A-DCCAC6034C1D%40icloud.com.

[Clark Sann]

Mark,

So what can I do with it if I get one? I’m programming the PRU in C, can I inspect variables and insert breakpoints?

Clark

[Mark Lazarewicz]

Been using emulators for 32 years in industry if you exclude debugging linux( printf is common) and look at bare metal or RTOS which many hard real time systems use you save time. IMO toggle gpio and printf is like erasing and programming eepeoms 30 years ago. Sure it works for applications but for low level bring up I won't work for a company that doesn't supply me a jtag. If your app uses the serial port your sol using printf. I recently worked at a company used an esp8260 Wi-Fi SoC project failed it took forever to reflash and once we added in the serial protocol printf was not possible. the lack of jtag killed the project. If your a student I get $90 of your own money may seem a lot but look at as an investment in your future every one uses jtag outside the linux community for RTOS and high end jtag like lauterbach used by ARM, TI etc etc cost thousands if dollars why do you think TI makes a cheap jtag and CCS support? Because for DSP ARM OMAP real world projects in successful products selling millions of units like the one I'm working on at work using omap138 Greenhills RTOS on the ARM and sysbios on the 687x DSP of omap and btw we use 2 PRUs this got to market quickly because of jtag. I will say this product is now debugged by loading binaries for DSP and ARM from a flash filesystem via telnet. T it took years to get that stable using you guessed it Greenhill sling shot jtag for ARM and CCS and jtag for ARM bootloader and DSP debug. I wasn't there when they debugged the PRUs its loaded from a c file by arm as is the DSP via shared DDR 

If you Google debugging the PRU with CCS you will find a tutorial for the bone PRU using CCS.

Get the skills employers use to deliver products quickly I bet you never look back. I Probally have a dozen jtag for a dozen micros 
I buy them as a learning aid to hit the ground running on any new processor I use. These SOcs are way to complex and life is way to short to wiggle gpios.

If you can't find the wiki I mentioned just ask 

Cheers

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+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/967BAFEF-EEB2-49CB-AB41-97A20CAF29AF%40icloud.com.