David Brownell pisze: > Normally a "reset halt" should have caused MAM and PLL to > enter their just-after-hard-reset hardware default states ... > > Are you saying those hardware default states cause problems? > If so, that seems buggy. I'm not sure where the issue would > lie, but it's hard to imagine the chips could boot properly > if the hardware defaults didn't work ...
Well, all LPC2xxx chips are "srst_pulls_trst" - that's the first thing. Moreover - due to internal bootloader operation there is some delay between de-asserting reset and activating the JTAG interface (this is some protection mechanism). That's why on LPC2xxx "reset halt" does: 1. reset 2. wait a while 3. halt 4. do a soft_reset_halt during 2. there is enough time for the core to execute A LOT of instructions, like enabling MAM and PLL, which DO cause trouble whan you expect them to be disabled. I haven't investigated that much, but I thing there is some hidden bug in soft_reset_halt, that makes programming (via gdb's "load") fail with "target not halted" (and yet - just before the "load" a "poll" command shows, that the core is halted /; ) > 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? One way could be to implement some king of hardware reset (maybe via Watchdog?), the other - to halt the execution in some infinite loop... 4\/3!! _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
