Ok, it looks like CS7 is the culprit. If I drive CS7 low with JTAG, then I can read the full D0..D31 of the data bus. CS[1,2,3,6] don't seem to have any effect upon the reading of the Flash array.

Is CS7 the only signal required to be deactivated?

(feel like I'm talking to myself here..., For the sake of documenting what I've done, I'll continure this thread).

From within the Jtag software (use the CVS version: http://openwince.sourceforge.net, I can kick the CPLD out of the way and gain read access to the Flash with a series of script statements:


Note: the JTAG wiggler that I'm using is a homebrew built along the lines of the HRI wiggler: http://http://hri.sourceforge.net/tools/index.html#jtag. Make sure you ground unused inputs and use a 74HC device as they will operate across 2.0..6.0 volt range. The transistor used is a common 2N2222 or, you could use a 2N7000 FET and eliminate the base-bias resistors of 10K & 47K. The goal here is to develop a Linux based JTAG tool that can be used to recover the Flash and for use with gdb for program development later on. I'll post a webpage with this information later.

Running Jtag with "Jtag <scriptfile>" will execute the above statements within the scriptfile and exit when they are completed. The sample.bin file is a 210K+ file that I burned into flash via lolo and then read back using Jtag. The contents were compared and found to be an exact match.

So, I have the ability to read the Flash via the JTAG tap port. What I need to do now is be able to write to the Flash and it seems that the CPLD "is in the way". There only appears to be one write signal to the CPLD and five chipselects. Process of elimination seems to suggest that by using a combination of CS7 + uP_nWE0 that the internal registers can be written to via JTAG.

However, it is not the case. Writing into the CPLD from the CPU with JTAG port does not appear to have any effect. Maybe there is a clock missing that the CPLD needs? Or, there is some other signal(s) that needs to be activated or de-activated?

Ok, getting closer. I can control the FL_VPEN output of the CPLD via JTAG. Here is the entire script needed to set FL_VPEN HI (enable writing to Flash memory cells), to use it, run Jtag then 'script <filename_of_this_script>':
FL_VPEN is now high and seems to be latched in that state. Accesses to the Flash doesn't seem to affect the state of FL_VPEN.

A little more work in the Jtag software by implementing a tandom write function to assert both uP_nWE0 and uP_nWE3 when talking with the flash now allows the CFI to be seen. But the values look suspicious, look at the Maximum Chip erase timing, 0ms?

Also, when I run an eraseflash (leaving VPEN disabled!), I get the wrong manufacturer device ID:


This is getting really close, but I am not yet ready to activate VPEN and truly attempt an erase yet.

The schematic calls out for an RC28F128J3A-150 device tor the Flash, but the devices on the board don't have that number. They are marked 4LC11FW406, what are those things?

OKAY! It works! I can now program / erase / verify the LH7A400 card engine Flash using a $10 wiggler and Jtag. There is still an issue with getting the CPLD to accept a value at 0x71000000, this is something I'm not initializing or signal timing related.

I'll package this up in a few days and send the patchfile up to the maintainer.

TomW,

Thanks for posting your findings to the Technical Discussion Group. Glad to see that you were able to resolve these issues!

Regards,

Platform Support