-atlas wandering-
Bloggorama for breaking things

\

• /(75)

Subscribe
Subscribe to a (RSS) feed of this weblog.

Archives


This Blog

atlasutils-2.2.19.tgz

showstopper arm/jtag bugs

let's see, most of these were discovered while driving long distances. not recommended but somewhat highly effective... somehow it's easier to focus on coding when email and phone and other work aren't expected.

i don't remember all the major bugs, but here are a couple i've had to overcome in my own jtag/arm code:
* unsigned long - i rewrote travis' jtagtransn code since his was targeted at 16-bit micros. my code allows for variable bit-lengths, up to 32 bits instead of the static 8/16/20 the original code allowed. apparently i had not used appropriately large variables to shift up to 32 bit positions, and things worked great until i was shifting past 16-bits. doh! unfortunately at this point i was still so green that finding this bug was so very painful. thankfully i was able to use travis' debugging code, add the debughex32 function and print out values quite easily in my interactive python session.

* arm's word-alignment - jtag writes instructions into the instruction pipeline to read/write registers, and just about every other thing it does. the instruction to write to a register is basically LDR Rx, [R14]... load whatever is at the memory location stored in r14 into whatever register you're setting. instead of loading from memory, the jtag interface provides whatever value needs to be coming "from memory". worked pretty good, but while testing i always ended up corrupting it and occasionally when i *wasn't* testing i would dork something up, and rather than writing 0x47145, it would write 0x4714500, 0x45000471, or 0x71450004. it was a real mess. after *much* gnashing of teeth i figured out that if the value in r14 was not perfectly word-aligned (ie. r14 % 4 == 0) the value i handed in was being shifted accordingly. sheesh! before this process i was a jtag n00b, but now i'm rather bruised... but confident i know what i'm talking about.

* dclk timing - i had all the foundational things working, breakpoints/watchpoints, halting, reading/writing registers... everything that had to do with the EmbeddedICE or running instructions at debug speed. unfortunately, the fun stuff really starts to heat up when running instructions at system-speed (the clock everything else like memory and peripherals is running at). rather than handing in information to write in a register, actually having the data pulled from memory, and vice-versa. basically, you insert a breakpoint in a nop just before the instruction you want to execute at system-speed, provide the instruction into the pipeline, then write the "restart" jtag instruction into the jtag instruction register. should be easy as pie. but try as i might, i could not get things to execute at system-speed. it's like that restart just never occurred. in fact, it wasn't. troubleshooting such things is a nightmare. i ended up writing python code to interpret the jtag events out of my oscilloscope... it was really neat when i got done, but wow, the suck. i love doing cool stuff... but when i'm sticking tons o time into something i'm not sure is worthwhile, it's not so fun. as it turns out, i was dragging the jtag state engine through "run-test/idle" haphazzardly. well, when the arm7 chip is in debug mode, each time the state engine passes through "run-test/idle" it provides a tick of the debug clock. without caution, too many hits of dclk can make that breakpointed nop slide right through the instruction pipeline before i set the restart instruction... no worky. so, ultimately, while troubleshooting this bug, i scrapped everything, started a brand new c and python code chain, provided only mandatory functionality into the embedded c code and reimplemented most functionality in python, and cleaned up the handling of dclk... and all was well.

sure, fine, go pick out bugs in the code... i hope you do. the GoodFET is to embedded hardware what vdb is to software.

@

[] permanent link / /

battlemechs ho!

holy crap, haven't had so much fun destroying things in a while.... a local gaming shop just opened up and they have six battletech pods. sure enough, they are just like i remember them from 15 years ago. only difference is, back then they cost $9 for a 10-minute mission. at the ulx gaming on plainfield in grand rapids, they cost $1.50 for a 10 minute mission. not only cheaper, but i actually can afford it.

anyway, hacking fun hardware stuffs. mostly been doing stuffs that my jtag/arm code for the GoodFET helps with. the jtag/arm is coming along nicely. once i figured out about 4 show-stopper bugs (ie. i couldn't buy a vowel to make things work right) new development is no longer like pulling teeth (like people around my neighborhood have any to spare!). ended up moving the majority of the code into the python side on the host (yes, invisigoth, you were right ;) basic arm7tdmi crap done, now it's just a matter of implementing flash and other chip-specific code. too bad i'm kinda focused on an arm chip that doesn't have built-in flash and i'm having to write code to control external flash... but pretty soon i'll be able to play with some code and make the sam7 chip bow to the GoodFET. (http://goodfet.sf.net/)

hack fun!
@

[] permanent link / /