Hi Gary, I think the 8 kHz is the problem here. I have read somewhere that the CPU speed must be 16 times faster than the jtag speed for reliable operation. This means that with a 32 kHz clock, the jtag speed must be 2 kHz, or lower. I have tried myself and it seems to work correctly at 4 kHz and lower. So 2 kHz is on the safe side. I tried 8 kHz and then the system was not stable. Every time I got different errors.
For interfaces with RTCK functionality, I can recommend this feature. It works perfectly for me. With this feature enabled you don't need to switch the jtag speed during a reset. It is much faster with these slow clock frequencies. So, I recomment that this script is changed. 8kHz should be replaced with 2 kHz for reliable operation under all circumstances. It would be nice if the script detects if the RTCK feature is enabled. If it is, no switching of the jtag speed should take place. Ferdinand Gary Carlson schreef: > Ferdinand, > > Using two patches, (yours + mine) I have "reset halt" and "reset run" > working reliably for the jlink dongle. While "reset init" works sometimes I > am finding the command can cause the jlink dongle to permanently lose > communication in some cases: > > reset init > JTAG tap: at91sam9260.cpu tap/device found: 0x0792603f (mfg: 0x01f, part: > 0x7926, ver: 0x0) > JTAG Tap/device matched > target state: halted > target halted in ARM state due to breakpoint, current mode: Supervisor > cpsr: 0x000000d3 pc: 0x00000000 > MMU: disabled, D-Cache: disabled, I-Cache: disabled > 8 kHz > WARNING: unknown debug reason: 0x0 > invalid mode value encountered 0 > cpsr contains invalid mode value - communication failure > Runtime error, file > "/usr/local/openocd-config/target/unknown-board-atmel-at91sam9260.cfg", line > 3: > > WARNING: unknown debug reason: 0x0 > invalid mode value encountered 0 > cpsr contains invalid mode value - communication failure > WARNING: unknown debug reason: 0x0 > invalid mode value encountered 0 > cpsr contains invalid mode value - communication failure > invalid mode value encountered 30 > cpsr contains invalid mode value - communication failure > invalid mode value encountered 0 > cpsr contains invalid mode value - communication failure > . > . > . > > You have a different type of dongle so I am curious whether you see this > problem as well. Knowing this will help me narrow the problem down further. > > Thanks, > > > Gary > > > On 8/6/09 2:48 PM, "Ferdinand Postema" <[email protected]> wrote: > > >> ==> How did you discover this fix? >> >> First I tried if the breakpoint version worked. It did.Then I inserted >> some commands to read back the vector catch register, to see if it was >> writen correctly. Then the vector catch worked! Then I tried a couple of >> things to see what was minimal neccesary. I tried waiting for 100000 us, >> but that did not work. Then I tried the extra cycle in state TEST >> RUN/IDLE and that worked. I think this should not influence other >> targets. It's just one extra cycle of doing nothing before the reset. I >> think it can be committed. >> >> Gary Carlson schreef: >> >>> On 8/6/09 2:14 PM, "Ferdinand Postema" <[email protected]> wrote: >>> >>> >>> >>>> I found a solution to my problem. It seems that this module needs one >>>> clock cycle in state RUN TEST/IDLE between the setting of the vector >>>> catch and the reset. Then it works perfectly. I tested it with the >>>> RTCK-feature and on 1 kHz, 2 kHz and 4 kHz. It didn't work at 8kHz, >>>> because the chip clock falls back to 32 kHz at reset. I have attached a >>>> patch file to include the extra cycle in state RUN TEST/IDLE. >>>> >>>> Ferdinand Postema schreef: >>>> Index: src/target/arm7_9_common.c >>>> =================================================================== >>>> --- src/target/arm7_9_common.c (revision 2571) >>>> +++ src/target/arm7_9_common.c (working copy) >>>> @@ -1015,6 +1015,7 @@ >>>> { >>>> >>>> > > > _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
