We designed a board with the Net+50 part in Jan 2002 and had the design reviewed by NetSilicon. We used the reset circuit that was on the development board available then. We have always had trouble with the Raven JTAG interface and was given a new reset by NetSilicon last summer. The JTAG situation was somewhat better, but still marginal. I now see a new reset circuit (Nov 2002 app note). My question is - is this new design any more reliable? Our JTAG problems seem to involve losing control of the processor through the JTAG port and we usually have to power everything (including the laptop driving the Raven) down and then up to get another variable period of operation. We also have boards which will download flash rom code at one time and then fail the next. In other words our operation under JTAG control is very marginal.
Hi,We had similar problems. As a workaround, we are reseting/holding using OCDCommander (http://www.ocdemon.net/ocd_dbgr.exe) before trying the JTAG connection with GHS tools. The problem with the new reset circuit from NS, in my opinion, is that it requires a specific patch for toolchain and not the standard GHS toolchain for Arm. I was not intending to change my JTAG circuit and now, with your comments, this position is becoming stronger… We did some scripts to configure Net50, like: #---------- ; OCD commmander halt ; word 0xffb00000 = 0x4004a010 word 0xffb00008 = 0x08000E1E word 0xffb00030 = 0x00000000 word 0xffb00028 = 0x00000000 word 0xffc00000 = 0x0dcc0000 ;/cs0 (NVRAM) word 0xffc00014 = 0xff0004B0 word 0xffc00010 = 0x01000001 ;/cs1 (SDRAM) word 0xffc00024 = 0xff000070 word 0xffc00020 = 0x0000022c word 0xffc00020 = 0x0000022d #-------- OcdCommander is free and easy to use. Using a raven, it is possible to upload, run, disassembly, halt, reset, write, read …
Can you expand on “losing control of the processor”? We are seeing a failure mode where the (third party) JTAG utility tells us: debug control 00000000 debug status 0000000C target running target not stopped debug control 00000007 debug status 00000008 target not stopped i.e. we have also “lost control of the processor”. Is your failure mode the same?
I had some difficulty getting the Raven to work with my board initially. I found that a hardware reset before trying to download a program to RAM worked wonders - with this I can pretty consistently get the program up and running. If I don’t do a reset either the program fails to load at all, or I get an error at address 2 when starting to run the program. The Multi 3.5 interface is much better than 2.1 in this respect - it is at least aware that you had reset the processor since it last tried to talk to the target. My own hardware implements what I suspect is the “original” reset circuit (CPU and JTAG reset connected). On some boards this is done using links as per NetSilicon; on others the “link” is done via an FPGA. I did not seem to have as much problem when I first started, when I was using the NS development board. It took me a while to realise it was configured for 16-bit flash, whereas my board is 32-bit flash. Can’t remember what happened when I reconfigured the NS board. Steve