==> 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" <ferdin...@postema.eu> 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 @@
>> {
>>
> /* program vector catch register to catch reset vector */
>
>
>> embeddedice_write_reg(&arm7_9->eice_cache->reg_list[EICE_VEC_CATCH],
>> 0x1);
>>
> + jtag_add_runtest(1, jtag_get_end_state());
> }
> else
> {
>
>
>> _______________________________________________
>> Openocd-development mailing list
>> Openocd-development@lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/openocd-development
>>
>
>
> After being on vacation for several weeks, I started looking at this same
> problem today except that I am working with a AT91SAM9G20 using a jlink
> dongle. I tried your patch and it fixes my problem as well.
>
> How did you discover this fix?
>
> I am now curious whether this change will have any affect on non-Atmel
> processors. If it doesn't, I think this needs to be committed.
>
> Gary
>
>
>
>
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
