Hi, Im using LPC2364 with modified sample target/lpc2378.cfg with interface/jtagkey2.cfg and with modification reset_config none (I dont have connected reset to JTAG). My GDB flash init is:
target remote localhost:3333 monitor soft_reset_halt monitor gdb_breakpoint_override hard d b main c And I dont find out any strange behaviour. But there is several recommendations which you must take in care. 1) In setup PLL you must check if PLL is connected or if is locked -> if yes you must disconnect it!!! If you dint check it, it should produce some errors during setup JTAG interface. Im dont know why but this part is often missing in published code... 2) if you are using JTAG is highly recommended to add long busy wait before startup routine is called. (Im using cca 0.5 sec dummy wait) The JTAG start routine runs processor for a while -> it runs application code. Jirka 2009/9/21 Freddie Chopin <freddie_cho...@op.pl> > 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 > -- =================================================== Bc. Jiri Kubias Czech Technical University in Prague Faculty of Electrical Engineering dept. of Control Engineering Karlovo namesti 13/E, 121 35 Prague Czech Republic web page: http://dce.felk.cvut.cz e-mail: jiri.kub...@gmail.com mobile: 777 974167 ===================================================
_______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
