Archive for June, 2006

OpenOCD forum moved, and some updates

Monday, June 12th, 2006

The forum system at Berlios is a bit unhandy to use – at least when you’re used to the features offered by other systems. Tsvetan from Olimex has been kind enough to ask Sparkfun to host the OpenOCD forum, and they’ve just set up a new section at their forum. Thanks to both Tsvetan and Sparkfun. The new place to ask for help with OpenOCD, to discuss new features you’d like to have, or just to let everyone know what you think about OpenOCD is

The support for Intel XScale based devices is coming along nicely. So far uploading the debug handler, entry into debug, core register handling and memory access works. Working with the XScale requires the ability to identify some ARM instructions, to be able to calculate the next address that’s going to be executed. I decided to add a complete disassembler to the OpenOCD, which is now (trunk, revision 68) available from the telnet interface:

> armv4_5 disassemble 0x0 11
0x00000000 0xe59ff018 LDR r15, [r15, #0x18]
0x00000004 0xe59ff018 LDR r15, [r15, #0x18]
0x00000008 0xe59ff018 LDR r15, [r15, #0x18]
0x0000000c 0xe59ff018 LDR r15, [r15, #0x18]
0x00000010 0xe59ff018 LDR r15, [r15, #0x18]
0x00000014 0xb9205f84 STMLTDB r0!, {r2, r7, r8, r9, r10, r11, r12, r14}
0x00000018 0xe51ffff0 LDR r15, [r15, #-0xff0]
0x0000001c 0xe59ff014 LDR r15, [r15, #0x14]

Branching, a few updates, and no more comments

Saturday, June 3rd, 2006

Yesterday I’ve changed the OpenOCD SVN repository layout to allow additional branches to be kept. The reason for this is that I started working on support for Intel XScale based systems. To be able to work on this without breaking the stable ARM7/9 stuff, I’ve moved the current stable OpenOCD code to /trunk, and created a new subdirectory /branches which for now holds the /xscale branch. Once I’m confident that any changes to the common code don’t negatively affect the stable stuff, I’m going to merge everything back into trunk.

To fetch the current stable OpenOCD, use the following svn command:
svn checkout

To fetch the XScale development branch (which is currently simply a copy of the stable code), use this svn command instead:
svn checkout

In the meantime, mostly bugs in the OpenOCD code have been fixed. These are, among others:
- “flash erase_check” would crash for CFI flashes when there was no working_area specified.
- register valid/dirty tracking was buggy. The result was an occasional “register xxx dirty but no valid data” error.
- The INTDIS signal wasn’t high during debug execution (i.e. flash writing, DCC downloads, …). This would corrupt memory or flash writing, if a system was already up and running with interrupts enabled.
- The working area reserved for LPC2000 flash operations was too small, and could corrupt flash writing.

Added/changed functionality includes, among others:
- Access to ETM registers. This is for a new project of mine, and isn’t currently usable (another reason for branching)
- DCC downloads have been disabled by default. Use the “arm7_9 dcc_downloads ” command to enable them. DCC drastically increases download performance (host->target), but requires a working area that must NOT be written to, and is potentially unsafe on targets running at a very low speed, like the 32kHz startup clock of some Atmel ARMs.
- Fast memory writes have been disabled by default. Use the “arm7_9 fast_writes
” command to enable them. Fast writes drastically increase download performance, especially when using a USB JTAG interface (Amontec JTAGkey, Olimex ARM-USB-OCD, homebrew).

There might be an issue left with LPC2000 systems:
If the CCLK frequency specified in the config file lists the crystal frequency, but your startup code enabled the PLL already, flash writing might fail. This has been reported only once so far, and a possible solution might be to manually turn the PLL off before starting any flash operations:

mwb 0xe01fc080 0x0
mwb 0xe01fc08c 0xaa
mwb 0xe01fc08c 0x55

Commenting in the blog has been disabled, because some spam bots sent me >10 messages per day. If you have something to say, use the forums, bug tracker, feature requests, or send me an email.