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

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/f0f2004d-f09e-4eb5-8601-606a78a50afe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to