I am looking into DCC to replace the uart logic (just for fun) that I have for monitoring the state of my arm, but I haven’t found any info if openOCD support this “feature”, some sort of debug agent (per arm docs) or RTAgent (per Keil docs).
My idea is to sent a word(sync header,cmd,value1,value2 - 32bits) to dcc using jtag then a small monitor code in my mcu will decode and execute a given command… currently I am thinking on set-address-to-read and read command for now (but the sky is the limit) that will read a specific piece of memory… from the debugger point of view, I will sent this commands via the telnet implementation from openOCD or through eclipse ( could be nice).
But here is the tricky part, currently I don’t see how to do it, because eclipse doesn’t support this live-update feature either openOCD, I might wrong?!?! I am using the good dog yagarto toolchain distribution and the ARM is a LPC2129.
What I know is that you can use openOCD for flash programming with DCC… so the DCC functionality is there…
So, does anybody have done this before? any pointer are welcome!
I downloaded the source code for openOCD, but I don’t know where to start! I just need some pointers to the code that do the DCC flash programming… I guess is going to be different for each brand and family… but I will focus in just the LPC’s…
I am thinking in that I need to create a new command for the telnet server to be able to trigger the read from dcc and display information in the screen… obviously my embedded code needs to have some stubs to recognize this request and send back the requested info…
mmm!!.. I do not quite understand! Of course I want to use openOCD. =) Actually I am using it… so I can download firmware to mcu and step over the firmware, but I haven’t seen a live-update feature… where I don’t need to stop the code/application to readback variables… so if I hit “run” I will still see the values of my variables changing in the watch window…
but I might missed that feature… I tried to see into the code, and I found the dcc_download code, but not quite the feature that I was looking for…
ohh! I see, let me understand this better… to create this feature, we are talking about a openOCD with a new fileIO implementation? or is on the fw itself? My believe is the firmware! I might wrong!!!
Thinking about it, I see 3 places where something needs to happen:
eclipse plugin(CDT Zylin?), where we you can set a flag to update the watch window in real-time.
openOCD, implement a piece of software awareness to look at dcc every x time. (a lot of overhead here)
application firmware, where developer needs to added something to be able to walk using DCC.
Do you know who has this feature implemented, besides Keil? does it Rowley IDE has it?
What alejmrm is looking for seems to be different from what I know as semihosting.
Semihosting is a way for the target to use the host’s I/O resources like filesystem and console. Supported functionality could be something like GDB’s F-packet: http://sourceware.org/gdb/current/onlin … tml#SEC678
For this to work we would have to write the target stubs for the various to-be-supported syscalls and the code inside OpenOCD that translates these requests into GDB F-packets. The obvious advantage of using GDB is that all the actual I/O handling is already implemented. The problem with this approach is that in the current design, GDB is only thought of as one possible frontend - telnet is another one. There’s also at least one commercial frontend I know about called NoICE. NoICE uses the GDB remote protocol to talk to the OpenOCD but probably doesn’t know about the F-packet.
What aljmrm suggested is basically monitor mode debugging, using something like Angel or RealMonitor (both ARM things). It allows limited access to the target without having to halt it. The target therefor regularly checks the DCC for pending data and executes these requests, probably from an idle loop or some other non-critical part of the program.
Incidentally I’ve been looking into adding support for “trace” outputs from the target using DCC. This would be a first step towards full semihosting. I’m planning to add regular polls for DCC data and a simple command scheme:
Bits 0-15: command
Bits 16-31: optional data
For now, the only command would be TRACE with a length of the trace message that follows as an argument:
Bits 0-15: 0x0000 (TRACE)
Bits 16-31:
Maybe the command could also be split into a main command and a sub command:
TRACE
ascii
hex
…
F-Packet
open
write
…
I’ll write some code for the TRACE command tomorrow.
I went to the above website to read about the “F” command… and I guess to be able to readback any data from our target mcu using eclipse we need to translate the ddc info into gdb protocol; so eclipse or any gdb compatible debugger will be happy reading back this info.
the chain of events is as follow: (this is my guess)
From MCU to eclipse:
MCU App → SWI → DCC/VIC → FTDI IC → openOCD SW(new magic here) → GDB server → eclipse.
So in this way, anyone can connect to the target using telnet and issue a query like this: dcc_read addr len
In this way I will avoid the gdb part(looks really huge) and write a “small” application in DOS using socket and readback info…
my 2 cents!
[update]
interesting the GDB protocol… I always swear is was a binary protocol, but seems to be ASCII base, that’s makes easy to read a raw stream coming from GDB…
: