From: Spencer O. <sp...@sp...> - 2014-01-29 09:59:06
|
On 28 January 2014 22:39, Steve Franks <bah...@gm...> wrote: > Interesting. Still picking away at it. Today I wondered if the hex in > flash was crashing it so hard I couldn't debug. I put an old hex on > there, and it does look to have halted at first (although there's a > lot of error messages in there). Then I started getting breakpoint > errors. I don't know if that's because the hex doesn't match the elf > I'm using with the debugger (should'a kept my old elfs but I didn't), > or if it's still just as broken as before.... > Firstly I would say that log does not look too bad, enough to get you working. However one bit of advice it to try and stick with the default configs where possible. I noticed in your last email you were tweaking the Olimex config, it is very rare you would need to change this. Reset it quite complex, we have three areas to think about. 1. What the adapter supports 2. What the target supports 3. What the board has connected. We know TRST is optional from a JTAG point of view, however we need to add 'srst_pulls_trst' if we know that your hardware connects SRST and TRST together. So as a start create an openocd.cfg that contains something like -- source [find interface/ftdi/olimex-arm-usb-ocd.cfg] source [find target/lpc2148.cfg] # change the cfg default reset_config reset_config srst_only # for initial script debugging change default adapter speed adapter_khz 500 # below added as a reset test init reset init -- What happens if the above script executes, hopefully we should be reset and halted? It is worth getting this correct before we bring gdb into the picture. Cheers Spen |