Hi Jim, > Good idea. I don't know SWD well enough to interpret this at the moment, > but here's the captured data: > http://jim.sh/~jim/tmp/openocd/
Interesting... Unfortunately I don't have a huge amount of time to devote to this and my head isn't really in nrf land at the moment, but here's what I see from looking at the dump: At flash.log:682 (time 712) the first failure is code 0x16 from the STLINK, which comes after writing value 0x20000828 to RAM address 0x20000020 (wp_addr for the async algorithm, so a sign that "I've written new data up to here" in the buffer, triggering the async algorithm to write to flash). Then it's waiting for the core to halt (which would normally happen after all data has been written to flash). The next long sequence of reads is polling the target state by reading 0xe000edf0 (DHCSR - Cortex Debug Halting Control & Status Register). The return status the first few-dozen times is C_DEBUG_EN/S_RETIRE_ST for "executing". Then we suddenly get back 0xf000000 for DHCSR which, as far as I can see in the Cortex docs, is a totally invalid value and the reason why the adapter throws error 0x16. Then the adapter issues a write to DHCSR of 0xa05f0003, which I think is an attempt to reset it to a sane value, and tries to write to the nrf register address space (at 0x4001e504). This seems to succeed(?) at the SWD level but the adapter returns error 0x17 to openocd anyhow. So, I think this puts the blame back on the nrf51/async loader side not the stlink side. Some ideas: * The async loader perhaps keeps executing much longer than it should until eventually something in the core faults and it needs a reset. * There's a race condition with the nrf51 while halting, and DHCSR value 0xf0000000 is the symptom. Possibly when this happens just polling DHCSR a second time will return a valid value. * Some other race condition between executing a breakpoint instruction and polling the debug port causes the debug port or CPU to go into an invalid state. * Is it only a problem that triggers when the total write size equals the working buffer size, or does it also happen on other combinations? If it was up to me, I'd first try adding a special case in stlink_usb.c stlink_usb_state() to re-poll status of DHCSR on an error value of 0x16 or 0x17, and see if that fixes the problem from an nrf51 hardware quirks end. That's probably not a permanent fix (as the problem seems target-specifc not adapter-specific), but it'd be an easy way to rule it in or out. Otherwise, from a software race condition angle, try continuously dumping the values for r0...r3 from the CPU while it runs the async algorithm and see where it gets up to. Angus ------------------------------------------------------------------------------ _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
