Reading RAM using the SX-Blitz

darco

Is there any way to get a RAM dump using an SX-Blitz? I don't need full debugging capability, I just need to be able to get a memory dump. It seems like there isn't any good reason why the SX-Blitz shouldn't be able to do this, other than just not being implemented in the firmware. I'm talking to the blitz directly, and not using the windows software, so even a protocol description would be useful if it exists.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
—
darco
www.deepdarc.com/

NetHog

The SX-Blitz doesn't allow dumping/reading of memory. It seems that the method of programming/verifying the SX is "cheeper" then the method of inspecting/debugging the SX Hence the price differences between the key and the blitz. If you think about how you would read contents of RAM, you'd need to freeze the program in step, and read off the run-time state of the processor... which is a major aspect of the debugging functionality.

Now, if you have a spare microcontroller around and spare bits, you could add some tracing functionality to your project.

darco

I was thinking that the primary reason that the blitz was cheaper was because it didn't include the clock generation circuitry, which is required for being able to step thru code, etc.

I totally understand how it wouldn't be physically possible for the SXBlitz to be able to do things like set breakpoints or step thru code... But it seems to me that if it can extract the contents of ROM, then it should be able to extract the contents of RAM too. If the firmware can't support this, then it might as well not be possible in hardware...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
—
darco
www.deepdarc.com/

Guenther Daubach

darco,

writing and reading the SX program memory is a feature that is implemented in the chip's silicon. It can be done in serial or parallel mode, according to the Scenix/Ubicom/Parallax specifications. The SX-Blitz makes use of the serial mode for erasing, programming, and reading the program memory.

In order to have access to the SX RAM section, it requires execution of some extra code in program memory of the target SX. This code is automatically added to the application code you send into an SX when you program it for debugging with the SX-Key. In order to execute this extra code together with the application code, it is necessary that the test device generates the clock singal for the target SX. As the SX-Blitz does not come with a clock generator, there is no chance for using it to read the contents of the RAM - you will need an SX-Key to do this.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,

G

NetHog

(Edit to note, I was writing this before Gunther replied, and posted before I saw Gunther's reply that nicely summarises what I say below)

There's a document "DeviceProgramming.pdf" (can't remember link) that describes the exact programming protocol. As part of this protocol, the device is reset internally (section 8.6.3). This mechanism therefore isn't very useful even if it could read RAM as the very nature of reset changes some of the RAM contents, even though there are 7 "unused" programming commands.

Interestingly, c/o http://forums.parallax.com/forums/default.aspx?f=7&m=56795 and http://www.sxlist.com/techref/ubicom/secrets.htm there is a set of "hidden" debugger instructions used for debugging. Note that these are instructions and a debug monitor is loaded into EEPROM as part of the above programming step that uses these instructions.

Also interestingly, OSC1 is external clock input, OSC2 is input/output, OSC2 is used as the data bit for serial programming, and there is a hidden instruction to read/write the "OSC pin" (It obviously makes sense that this reads/writes the I/O OSC2 pin and not the input-only OSC1 pin).

So for debugging to occur we can deduce the following happens:
1) A debug monitor is written to EEPROM
2) The oscillator is configured as external for debugging (and the reason all the expense of the external oscillator exists on the KEY is to effectively free up OSC2)
3) The debug monitor in EEPROM and the KEY talk to each other using OSC2 (which is the same data pin as programming)

When reading a byte from RAM, what effectively happens (by deduction) is this:

1) The program breaks into the debug monitor
2) Commands are sent via OSC2 to request a byte of memory is read, the debug monitor in EEPROM reads this and interprets it as a read of memory
3) the KEY converts received serial data into RS232 packets.

Now, theoretically if you wrote your own debug monitor that used the right serial protocol that the KEY recognizes, the Blitz should in theory be able to send that data back to the calling application if (and only if) this is not blocked by the blitz logic/microcontroller.

Alternatively, if you you design your own programming logic using the above spec, you could write your own monitor to dump RAM. But in that case, why use OSC2? You could use any bit for this.

Post Edited (NetHog) : 12/17/2007 1:19:30 AM GMT

Guenther Daubach

NetHog,

your detailed description about the internal workings of the debugger is correct. As you had mentioned, a debug monitor code using these "hidden" instructions must be running on the target device with an external clock fed into the OSC1 pin, and the OSC2 pin used for serial data I/O. The problem with the SX-Blitz is that it does not supply the clock that is required to run the debug monitor, and that the firmware of the SX20 on the SX-Blitz board does not support serial communication with the target device via the OSC2 pin. Therefore, the Blitz can't be used for reading out the RAM contents.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,

G