On Monday 21 September 2009, Freddie Chopin wrote: > > I think the fact that it doesn't work reflects a bug. But I > > don't know those LPC chips, or thus where the bug would be. > > That's a silicon limitation of LPC chips... For example in CrossWorks > this is overcome by injection a startup with a "forever loop" that is > later skipped by the debugger - this way at the start of the debugging > session the chip is in good state. Unfortunately something like this > cannot be implemented without build-tools integration /; Or maybe I'm wrong?
It could be something that LPC2xxx developers "just need to do" when debugging. If Crossworks chose that approach, I suspect it turned out better options were not available... Easy enough to have an #ifdef JTAG_DEBUG around such a loop, and set that flag. (I have an #ifndef for that symbol already, to prevent use of the WFI instruction in the idle task. Without it, the board is pretty much not debuggable: WFI prevents detecting the JTAG clock.) It's not that unusual, it seems, for debug-capable builds to need to spin for a while right out of reset either... ISTR seeing docs suggesting that some Stellaris-based projects might need to do that too. On those board the issue is different. They can halt at reset just fine, no problems I've seen. But if the four pins used for JTAG need to be muxed for something else... you need to hold off remuxing them, and give a JTAG debugger time to do its thing, or you'll never be able to replace the firmware. - Dave _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
