Hi again.

Well, just checked flash's pin 16 and it does go low whenever jKeys start or "Detect" is clicked and comes back high after ~0.5 sec...
Can't think of anything else that prevents flash's identifying.

Best regards.

9u4rk wrote:

QUOTE:
Can't think of anything else that prevents flash's identifying. :angry:
Best regards.

The wrong flash address in the jkeys .def would do that.

With the pin unconnected, the STB will no longer boot, so you will never see if after the first boot stage, that pin is locked to Low Power mode/Reset.
You need to, at least, RESET the flash IC together with the CPU with the CPU reset signal.
Then you will be able to check on the PCB pad that was connected to the flash if the signal goes low by the end of the first boot stage.

A few months ago I've received a jpeg picture from Slugworth showing JTAG connections for a 5514 Pace 3100.
The main RESET signal looked connected directly to the flash IC.

Yes, agree with Slugworth. The memory mapping is perhaps different in your STB.
The memory mapping for the Sti5516 is the following.


The Sti5517 is likely similar.
Here is the config from the 5517FTACI :

Code:

## Sti5517 EMI configuration file ## ## Purpose: Register pokes to configure EMI memory and peripherals on an MB382 eval board ## ## Bank Memory Space configuration: ## ## Bank0 0x40000000-0x4fffffff SDRAM 32Mbyte (256 MBit) ## Bank1 0x50000000-0x5fffffff STEM0/SRAM (256 MBit) ## Bank2 0x60000000-0x6fffffff STEM1 (256 MBit) ## Bank3 0x70000000-0x7effffff ATAPI/DVB-CI (240 MBit) ## Bank4 0x7f000000-0x7f7fffff DVB-CI ( 64 MBit) ## Bank5 0x7f800000-0x7fffffff SFLASH 8Mbyte ( 64 MBit) <--------------- ## ## ===========================================================================================

Try to change this in your .def file :
IRDFlash, 3, "M58LW032C", 0x8822, 0x7FC00000, 0x400000, 2, 2, 0
to
IRDFlash, 3, "M58LW032C", 0x8822, 0x7F800000, 0x400000, 2, 2, 0

you forgot to change the flash size from 4meg to 8meg

Hi guys.

Tried what @YLG80 posted, after flash's size correction, but still no success...

Been searching the web and found this:

QUOTE:
Quote:
Originally posted by dssseller0001
When opening jKeys, it correctly identifies the Microprocessor as STi5516FWB-X.
End quote
This is a TAP identify operation which does not rely on the flash definitions.

Quote:
I changed the IRD Model to DRD435-455.
I changed the Save Memory region to my new Flash 2 setting for the M58 chip.
Clicked on "Save Mem" and waited for a while...

.bin seemed to save correctly, so I opened it up in a HEX editor and compared the beginning of the file to a known, good .bin from a similar flash.
End quote
This uses the DCU READ operation which does not rely on the flash definitions (except maybe the start address and length).

The second quote is what makes me think; again, I don't know how jKeys works so I can't take it any further. Maybe you guys know better...
This is a discussion about the STi5516 and, if you want, you can follow it here: http://id-discussions.com/forum/showthread.php?t=63320

Best regards.

From your topic #57 showing an erro returned by Jkeys, it appears that jkeys is unable to recognize the mfg code.0xFFFFFFFF means that the data returned was not consistent.
This could happen if the flash chip definition used is not correct for the flash chip.
Jekys could not use the correct sequence to address certain flash registers containing the Mfg data.

You sould be absolutely sure that your flash is an M58LW032C not 32D which has a different structure and a different manufacturer code.

The DCU3 trap is not necessary to fetch the CPU ID or read the flash. It's necessary if you want to erase or reprogram the flash or have access to the RAM.

So, if there is no special trick to put the flash in Reset/Low Power Mode, you should be able to read that flash with a standard jkeys compatible interface correctly wired to the jtag connector.

On the M58LW032C

QUOTE:

READ MODES
Read operations can be performed in two different
ways depending on the settings in the Configuration
Register. If the clock signal is ‘don’t care’ for
the data output, the read operation is asynchronous;
if the data output is synchronized with clock,
the read operation is synchronous.
The read mode and format of the data output are
determined by the Configuration Register. (See
Configuration Register section for details).
On Power-up or after a Hardware Reset the memory
defaults to Asynchronous Read mode.
./..
On power-up the memory defaults to Read mode
with an asynchronous bus where it can be read in
the same way as a non-burst Flash memory.

Jkeys needs to use the correct mode for that flash chip.

in 2006

QUOTE:

./..
I am still having problems about working with the ST M58LW032D and M58LW064D FLASHes in situ even with ST developer project source code written specifically for them at the moment but should soon have it resolved.
./..

Seems to be a difficult chip to read !

Hi guys.

I'm pretty sure it's got a M58LW032C flash...

QUOTE:
Seems to be a difficult chip to read !

Yes, looks like it is , but when this happens, the more it drives me.
The main problem is we don't know what's the reason that prevents us from reading it. On the other hand, we read about people that have been able to do it with no hassle at all...
Where do we stand...?
Then again, there might be something (a special trick, as you said @YLG80) that keeps us from identifying it correctly. But what...?
Did I say before this drives me? All right, it drives me... It drives me nuts!

Best regards.

did you ever get past the dcu peek error stage?

Hi there.

No @slugworth, never!
I guess that might be the reason...

Best regards.

You might want to try a different pc also.
Sometimes parallel ports are finicky.

I've examined your JTAG connector picture.
As far as I can see, each pin (except TRIG OUT) is connected via a resistor (located below the connector) to the rest of the circuit.
What are the resistance values ?
If you use a simple unbuffered interface already with resistors in each line, you might have a problems if there are also resistors in series within the circuit.

@ logic levels as low as 3.3V, you interface might be unable to correctly drive the JTAG signals or the signals might be very noisy with two resistors in series.
At 3.3V the noise margin is weak.

Also regarding the picture, what do you mean with PIN0 15 DA FLASH ?
Does that mean that this pad is connected to VPEN on the flash chip ?

I suggest also to wire your interface back to the classic JKEYS type for your next trials

Hi guys.

Been busy this morning, hope I get a quieter afternoon...
YLG80 wrote:

QUOTE:
I've examined your JTAG connector picture.
As far as I can see, each pin (except TRIG OUT) is connected via a resistor (located below the connector) to the rest of the circuit.
What are the resistance values ?

From left to right:
10K, NC, 75, 10K, 10K, 10K, 10K and 10K (the one furthest to the right and a little above).
YLG80 wrote:

QUOTE:
If you use a simple unbuffered interface already with resistors in each line, you might have a problems if there are also resistors in series within the circuit.

@ logic levels as low as 3.3V, you interface might be unable to correctly drive the JTAG signals or the signals might be very noisy with two resistors in series.
At 3.3V the noise margin is weak.

The way I see this, these are either pull-up or pull-down resistors (most of them anyway, didn't check all)
YLG80 wrote:

QUOTE:
Also regarding the picture, what do you mean with PIN0 15 DA FLASH ?
Does that mean that this pad is connected to VPEN on the flash chip ?

I suggest also to wire your interface back to the classic JKEYS type for your next trials

This has been given to me and no details were disclosed but I think it's to be connected to flash's Vpen when programming/erasing is needed, for it's a 3.3V line.

I'll follow your suggestion. I'm assuming the classic interface is the way I had it before (just reconnect nTRST to db25/5 and open nRST).

Best regards.

You are right, with such high values the resistances are likely pull-up or pull-down.

QUOTE:

I'll follow your suggestion. I'm assuming the classic interface is the way I had it before (just reconnect nTRST to db25/5 and open nRST).

That's correct. Keep short wires between the DB25 and the JTAG connector.
ref : http://jtagcables.com/jtag-cables/unbuffered-jtag-cable-xilinx-dlc5-cable-iii

With a buffered JTAG interface you can have longer wires (mine is about 30cm/12" )

Hi guys.

Have to go out again...
When I'm back will test some more. There are some issues in the flash's datasheet that I'd like to discuss with you guys.

C u in a bit, hopefully...

OK, in the meantime, I've tried to replicate your 0xFFFFFFFF error while using the Flash programming button the READ in Jkeys.
I can only replicate it when I wire my interface as for ucTAP.(CPU ID is correctly identified)
Even using the DB25 pin 12 signal connected at pin 19 JTAG CON and nothing at pin 17, I can fully read my flash memory.

Have you tried JKEYS on a lower speed PC ?

I don't have an sti5517 receiver with jtag points,but my sti5516 had the same
error until I used pin 17 instead of pin 19 on the db25.
4meg flash

Hi guys.
YLG80 wrote:

QUOTE:
Have you tried JKEYS on a lower speed PC ?

I'm going to try it on a PIII (1.1GHz) running Fedora 11. Will let you know the outcome...

@slugworth, I may be doing something wrong. The problem is I haven't been able to find out what...
Will cable lenght if too long or some misconnection, give me such errors?
Another thing, your CPU is STi5516 and what about flash, is it M59LW032C also?

Best regards.

P.S.: forum is looking nicer as time goes by.