I was finally able to figure out the cause of this problem. There are two parts to the patch. The first patch modifies the configuration file I originally generated for the Atmel AT91SAM9G20 board and achieves the following:
+++ Splits the reset-init handler into a reset-start handler for some of the initial configuration activities and keeps the remainder in the reset-init handler as was the case before. This was the real issue that was causing the timing problems I identified before. This solution was confirmed with an o-scope on actual target hardware. +++ Adds a new instruction in the reset-start handler to disable fast memory accesses in the reset-start handler. When the target jtag clock is started out at 2 kHz during system clock initialization, memory writes (i.e. register write to enable external reset pin -- basically to RSTC_MR) are naturally slow and cause GDB keep-alive issues (refer to PATCH 2/2 for additional fixes). +++ Modifies the configuration file to use srst_only reset action. The reset-start/reset-init handler split also now allows the correct behavior to be used in the configuration file (previously had to use both SRST and TRST even though only SRST is actually used and connected on the evaluation board). +++ Adds external NandFlash configuration support to take advantage of flash driver added earlier. Doesn't fix any bugs but adds functionality that was marked as TBD before and thrown in when I did other work on the configuration file. Gary Carlson Gary Carlson, MSEE Principal Engineer Carlson-Minot Inc. On 5/7/10 1:16 PM, "Gary Carlson" <[email protected]> wrote: > Hi Øyvind, > > Yeah...that actually is the problem. When I run OpenOCD under GDB -- even > without breakpoints -- the problem goes away completely (naturally of > course). I have no doubt that your assessment that it is related to timing > is likely correct. > > In the absence of not being able to use GDB to solve this problem, any > suggestions on particular areas of the code to focus? > > Gary > > > On 5/4/10 9:22 PM, "Øyvind Harboe" <[email protected]> wrote: > >> Maybe it's a timing issue? Have you tried single stepping through assert >> reset? >> >> > > > _______________________________________________ > Openocd-development mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/openocd-development
at91sam9g20-ek.patch
Description: Binary data
_______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
