Colin,

Is there anything in particular that you are having trouble with right now?

Hi Aaron

Here is the original email I sent to Nohau about 2 months ago:

Regards
Colin

Quote:

Hi

We have recently purchased a EMUL-PC/USB-JTAG to assist with development of a product, which in its initial implementation will be based on a SDK-LH7A400-10 starter from Logic Product Development (http://www.logicpd.com) We are using the ARM RVDS (Real View Developers Suite) and coding in C++..

So far I have had mixed fortunes getting the debugger to work with the SDK.

When I try and download my app (in AXF form) I am getting errors such as:

seehau.exe - Application Error
The instruction at "0x01f6912d" referenced memory at "0x4e455f5f". The memory could not be "read"

If I tell Windows to debug the program the following comes up:
Unhandled Exception in seehau.exe (STARM.DLL):0xC0000005: Access Violation

The version of seehau is 6.0720C.

The target address it seems to stop at is 0xC00CBF68. There is nothing unusual about this address and I can download OK via the loader shell that Logic provide in the SDK. I can also download my app as an SREC via Seehau.

If I do download as an SREC and then try and start from the same address I start from using the loader shell, Seehau comes up with the error:

Error Target did not stop when commanded to

This error was detected
in file: "c:\ncARM\Source\RUN_new.CPP"
at line 3311.
Cmd: Run_Break
Core: 0
Date: 1/02/2005 Time: 4:45:41 PM

Any ideas on what is going wrong?

Also, if you have pointers on working with the RVDS and/or the LogicPD SDK I would greatly appreciate them.

Many thanks
Colin Howard.

I'm also experiencing problems with RealView Debugger v1.7 from RVDS v2.1, although I use RealView ICE v1.2 as a JTAG "vehicle" to get to my Zoom LH7A404-11. I was previously able to stop the target when Lolo v2.0.2 was running on it, but since I had to overwrite Flash Block 0 with my RTOS's exception Vector Table, I can no longer do so. Now, RVD simply says "Unable to stop target". Helpful, isn't it! Without Lolo or anything else to boot the Zoom board, I'm completely dependent on my JTAG debugger to connect to it. That's the whole point of paying beaucoup $$$ for a JTAG interface, as opposed to a target-resident monitor program, like RelalMonitor or Angel, isn't it!?!?

I can't find anything in the docs supplied with RVDS 2.1, and the only hit I get when I search ARM's web site for that exact (double-quoted) error is something about Multi-ICE and a Coyote board. It appears that board requires an unusually long reset time and Multi-ICE can be configured to wait an extra amount of time before it attempts to communictae with the target after it comes out of reset. Knowing that the LH7A404 resets into Standby Mode & relies an external circuit to yank its wake-up signal (see Sharp AppNote "Implementing Auto-Wakeup on LH7A4xx Series Devices"), which I assume (shouldn't!) that the Zoom implements, I changed the equivalent parameters in RVConfig by a factor of 10, but that doesn't seem to help. I've opened a support ticket with the vendor that sold us the RVDS/RVD/RVI combo, but I sense it will be a major struggle. Anybody have anything to suggest? Anyone? Anyone?

Jean,
It has been our experience that having invalid opcodes stored in FLASH on the kit will sometimes prevent external JTAG debuggers from connecting to the ARM core. It seems the invalid instructions put the ARM core into a state that prevents it from communicating through the JTAG interface. One method we use to get around this dilema is to tie the uP_MODE3 to ground which re-routes the FLASH_nCS signal through the CPLD until the JTAG debugger has connected to the core. An easy way to do this is tie a wire or jumper from connector J17 pin 23 on the SDK kit to ground (J17 pin 24, 80 or others).
Give this a try, it may help.

Colin, the uP_MODE3 adjustment doesn't apply in your case.

-Kurt

Thank you, KurtL!!!! That worked first shot!!!! RVD was able to connect to the Zoom_LH7A404-11 with the flash unavailable. Problem was, I couldn't update the flash with the latest LOLO becasue flash was unavailable. Took me a little while to figure that out.

For the sake of someone else reading this in the same situation I was, let me just document what I did.

1) Place a jumper between AppEngine J17 pins 23 and 24 to stop the LH7A404 from being able to access the Flash chip @ 0. (so what's at 0???)
2) Hit the AppEngine reset button, connect RVD, and stop it.
3) Either download the old Bolo/Lolo v1.2.1 "recovery images" and follow AppNote 248 "Restoring a Corrupt Bolo/Lolo with an ARM Multi-ICE JTAG" from LogicPD's web site, or follow the rest of these instruction & use the latest version of Lolo that you wish your board to end-up with. I used v2.0.3 from 1003195.zip & I think most people will find it simpler to do the same.
4) Once RVD connects to your board, load the 1003195_boot.elf, and hit go. You'll see this little 1KB piece of code load & run out of the LH7A404's embbeded SRAM @ 0xB0000000 to init the SDRAM controller. Very quickly, it enters its tight NOP (MOV R0,R0) loop, & you can stop it.
5) AT THIS POINT, REMOVE THE JUMPER FROM J17:23-24.
6) Now that SDRAM is available, load 1003195_lolo_ram.elf, the RAM-loaded version of Lolo. It will start near the beginning of SDRAM @ 0xC0000000 to re-init the board and, since the J17 pin 23 (uP_MODE3) is not grounded, it will allow access to Flash @ 0.
7) Hitting "Go" in RVD will immediately display the Lolo v2.0.3 banner on your terminal screen. You can either "erase 0 0x100000", "load elf" & "File -> Send 1003195_lolo.elf" thru the TerraTerm serial connection (as I did), or since you've got full blown Lolo v2.0.3 connect via Ethernet to do a TFTP copy of 1003195_lolo.elf to Flash, or "update" using 1003195_lolo.upd thru the serial connection.
Reset your board and you should immediately see the Lolo v2.0.3 banner on your terminal screen as your board boots from flash.

Images in Lolo Zip file:
xxxxxx_boot.elf loads in & runs from eSRAM
xxxxxx__lolo_ram.elf loads in & runs from SDRAM
xxxxxx__lolo.elf loads in Flash & runs from SDRAM
xxxxxx__lolo.upd for a running Lolo to update its Flash

Again, thanks KurtL.

Jean,
Glad it worked for you! By tying uP_MODE3 low, the CPLD ties the processor chip select nCS0 to a signal called BOOT_nCS which goes off the card engine and is available for customers to connect up external flash that they wish to be able to boot from. In its default state (uP_MODE3 high), the CPLD ties nCS0 to the FLASH_nCS which is onboard NOR flash that the card engine typically boots from.

-K