Hi guys.

Thx for your concern, @slugworth.
Precisely what I first thought were the jTag points:

AC7 - TDI
AD7 - TMS
AE6 - TRST
AE7 - RESET
AF6 - TDO
AF7 - TCK

This is in accordance with STi5516's datasheet, but not the jTag points we have on this board and on Grundig's schematic (kindly uploaded by @YLG80).

Best regards.

Hi my friends.
I have one receiver with STi5517 (FUB ) and M58LW032A flash.I have past trough all the things @9u4rk has test untill now and I'm exactly in the same situation.DCU peek error in Jtag and same response in ST20tool.Like this:
-in ucTap

Code:

[write_ack]02 00 00 00 02 00 00 00 81 01 IDCODE read 759296065 [write_ack]06 00 00 00 06 00 00 00 a1 01 41 f0 Reset with no boot. Check IDCODE 2d41f041 [get_hosted_poke] val = 000000ff P[write_ack]02 00 00 00 02 00 00 00 a0 01 peek 1 words from 30003000 peeked ffffffff [write_ack]06 00 00 00 06 00 00 00 87 01 ff ff peek 1 words from 30003040 peeked ffffffff [write_ack]06 00 00 00 06 00 00 00 87 01 ff ff peek 1 words from 30003000 peeked ffffffff [write_ack]06 00 00 00 06 00 00 00 87 01 ff ff peek 1 words from 30003040 peeked ffffffff [write_ack]06 00 00 00 06 00 00 00 87 01 ff ff [write_ack]02 00 00 00 02 00 00 00 88 01 Poke 19 words. POKE 80000000 to 80000000 mask ffffffff POKE 80000000 to 80000004 mask ffffffff POKE 80000000 to 80000008 mask ffffffff POKE 80000000 to 8000000c mask ffffffff POKE 80000000 to 80000010 mask ffffffff POKE 80000000 to 80000014 mask ffffffff POKE 80000000 to 80000018 mask ffffffff POKE 80000000 to 8000001c mask ffffffff POKE 80000000 to 80000020 mask ffffffff POKE 80000000 to 80000024 mask ffffffff POKE 80000000 to 80000028 mask ffffffff POKE 80000000 to 8000002c mask ffffffff POKE 80000000 to 80000030 mask ffffffff POKE 80000000 to 80000034 mask ffffffff POKE 80000000 to 80000038 mask ffffffff POKE 80000000 to 8000003c mask ffffffff POKE 000000ff to 20013300 mask ffffffff POKE 00000000 to 20013300 mask ffffffff POKE 00000000 to 200130f8 mask ffffffff peek 1 words from 200130f8 peeked ffffffff [write_ack]06 00 00 00 06 00 00 00 87 01 ff ff peek 1 words from 200130f8 peeked ffffffff [write_ack]06 00 00 00 06 00 00 00 87 01 ff ff [write_ack]02 00 00 00 02 00 00 00 82 01 RECV ERROR: err=10053 closing 9737

-in ST20

Code:

C:\STM\ST20R2.3.1\examples\test5517>go Error - CLOCKGEN not in X1 mode. Reconfiguration not possible Aborting !

L4 (EMIBOOTMODE0) is pull down to ground ,I have tried to pull up at 3.3V,receiver don't boot but processor still recongnized and it's the same situation like before.Same with jtag and ucTap. Pinout is exactly like in Grundig schematic. First part from ucTap is like this:

Code:

Starting a server on 9737 Starting a server on 9735 [process_request_9735][9735] data = 128 05 00 00 00 00 00 00 00 packet 05 [process_request_9735][9735] data = 128 01 00 00 00 00 00 00 00 [process_request_9735][9735] data = 128 00 00 00 00 75 63 72 2e [process_request_9735][9735] data = 16384 71 21 58 72 e0 71 22 50 [process_request_9735][9735] data = 1136 48 76 2d 29 2f 92 25 fa [process_request_9735][9735] data = 16384 21 51 72 e1 71 22 23 59 [process_request_9735][9735] data = 1136 2f f1 72 71 23 28 31 2f [process_request_9735][9735] data = 16384 f0 71 63 2f 2d 98 c2 c0 [process_request_9735][9735] data = 1136 23 28 9d 75 f4 a2 64 0c [process_request_9735][9735] data = 16384 2d 21 95 72 37 ef 43 72 [process_request_9735][9735] data = 1136 76 28 25 2c 5c d6 21 01 [process_request_9735][9735] data = 13624 f9 a9 7a 59 13 22 25 29 [process_request_9735][9735] data = 16384 30 00 00 00 00 00 16 00 [process_request_9735][9735] data = 1136 00 44 01 10 02 00 00 00 [process_request_9735][9735] data = 16384 04 00 00 00 10 00 00 00 [process_request_9735][9735] data = 1136 00 00 00 00 00 00 00 00 [process_request_9735][9735] data = 16384 00 03 00 00 00 00 14 fe [process_request_9735][9735] data = 1136 00 00 00 00 00 00 00 00 [process_request_9735][9735] data = 16384 00 00 00 00 60 00 00 00 [process_request_9735][9735] data = 1136 03 00 00 0c 00 00 31 00 [process_request_9735][9735] data = 16384 11 0a 00 40 09 00 00 15 [process_request_9735][9735] data = 1136 00 00 29 ff 80 01 00 00 [process_request_9735][9735] data = 16384 04 00 4c 90 09 06 00 26 [process_request_9735][9735] data = 1136 00 00 00 00 00 00 00 00 [process_request_9735][9735] data = 16384 00 01 20 00 00 00 00 02 [process_request_9735][9735] data = 1136 00 04 80 00 10 00 02 00 [process_request_9735][9735] data = 16384 00 00 00 00 00 00 00 00 [process_request_9735][9735] data = 1136 00 00 00 00 00 00 00 00 [process_request_9735][9735] data = 4688 00 00 00 00 00 00 00 00 [process_request_9735][9735] data = 3416 00 00 00 00 08 00 00 00 [process_request_9735][9735] data = 28 c7 1f 01 00 bc 3b 01 00 [process_request_9735][9735] data = 16 33 22 01 00 2b 20 01 00 [process_request_9735][9735] data = 10 74 6d 6a 65 69 2e 64 62 [process_request_9735][9735] data = 128 01 00 00 00 75 63 72 2e closing 9735 Administrator@xxx connected on Thu Jan 28 14:58:32 2010 [get_hosted_poke] val = 000000ff P[write_ack]02 00 00 00 02 00 00 00 81 01 IDCODE read -1 [write_ack]06 00 00 00 06 00 00 00 a1 01 ff ff closing 9737

but this appears even if the receiver is stoped,so I guess is nothing useful.

And another thing: in ucTAPsrv.cpu is a little mistake.Put this line:

Code:

STi5517, 0x2d41f041, 0x30003004, 0x00000200

and ucTAP will recognize the CPU.Now the errors are like before plus this:

Code:

....... POKE 0000038e to 200130e0 mask fff POKE 00000000 to 200130e4 mask fff POKE 00000071 to 200130e8 mask fff POKE 000002b5 to 20013140 mask fff POKE 00003333 to 20013144 mask fff POKE 000002ed to 20013130 mask fff POKE 000048a7 to 20013134 mask fff POKE 00000231 to 20013120 mask fff POKE 00003600 to 20013124 mask fff peek 1 words from 20013004 !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed peeked 00000000 [write_ack]06 00 00 00 06 00 00 00 87 01 00 00 peek 1 words from 20013008 !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed peeked 00000000 [write_ack]06 00 00 00 06 00 00 00 87 01 00 00 peek 1 words from 20013004 !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed peeked 00000000 [write_ack]06 00 00 00 06 00 00 00 87 01 00 00 peek 1 words from 20013008 !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed peeked 00000000 [write_ack]06 00 00 00 06 00 00 00 87 01 00 00 peek 1 words from 20013004 !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed peeked 00000000 [write_ack]06 00 00 00 06 00 00 00 87 01 00 00 peek 1 words from 20013008 !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed peeked 00000000 [write_ack]06 00 00 00 06 00 00 00 87 01 00 00 peek 1 words from 20013004 !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed peeked 00000000 [write_ack]06 00 00 00 06 00 00 00 87 01 00 00 peek 1 words from 20013008 !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed peeked 00000000 [write_ack]06 00 00 00 06 00 00 00 87 01 00 00 peek 1 words from 20013004 !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed peeked 00000000 [write_ack]06 00 00 00 06 00 00 00 87 01 00 00 peek 1 words from 20013008 !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed peeked 00000000 [write_ack]06 00 00 00 06 00 00 00 87 01 00 00 peek 1 words from 20013004 !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed peeked 00000000 [write_ack]06 00 00 00 06 00 00 00 87 01 00 00 peek 1 words from 20013008 !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed peeked 00000000 [write_ack]06 00 00 00 06 00 00 00 87 01 00 00 peek 1 words from 20013004 !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed peeked 00000000 [write_ack]06 00 00 00 06 00 00 00 87 01 00 00 peek 1 words from 20013008 !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed peeked 00000000 [write_ack]06 00 00 00 06 00 00 00 87 01 00 00 peek 1 words from 20013004 !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed peeked 00000000 [write_ack]06 00 00 00 06 00 00 00 87 01 00 00 peek 1 words from 20013008 !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed peeked 00000000 [write_ack]06 00 00 00 06 00 00 00 87 01 00 00 peek 1 words from 20013004 !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed peeked 00000000 [write_ack]06 00 00 00 06 00 00 00 87 01 00 00 peek 1 words from 20013008 !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed peeked 00000000 [write_ack]06 00 00 00 06 00 00 00 87 01 00 00 peek 1 words from 20013004 !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed peeked 00000000 [write_ack]06 00 00 00 06 00 00 00 87 01 00 00 peek 1 words from 20013008 !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed !!!WaitStart failed [RxByte] failed peeked 00000000 [write_ack]06 00 00 00 06 00 00 00 87 01 00 00 [write_ack]02 00 00 00 02 00 00 00 82 01 RECV ERROR: err=10053 closing 9737

In ST20:

Code:

C:\STM\ST20R2.3.1\examples\test5517>go PLL failed to LOCK, Aborting Setup!

I never paid any attention to the uctap screen when I was playing with the
sti5105 jtag lku.I was more interested in the lku screen and error messages.
The lku may have the wrong ram size/addresses or other problems.

All you need in the .cpu file is:
STi5517, 0x2d41f041,
uctap will come up with it's own values for the other addresses.
It is more important to have the correct dcu3 settings in the .lku
Ram size/addresses are critical as people that played with the sti5105
jtag will tell you.

I still say you have to get jkeys working first without dcu peek errors.
Shorten your jtag cable down to a stub if necessary.
You need a good flash dump anyway before you even think of erasing.

Don't know when I'm gonna have time again,maybe next week.Gonna try again with jtag and studdy more about st20,hard to find adresses if there is no dump.

Hi guys.
slugworth wrote:

QUOTE:
All you need in the .cpu file is:
STi5517, 0x2d41f041,
uctap will come up with it's own values for the other addresses.
It is more important to have the correct dcu3 settings in the .lku
Ram size/addresses are critical as people that played with the sti5105
jtag will tell you.

I must agree with @slugworth: - As long as we have "DCU peek error" when we start jKeys, we won't be able to do anything.
On the other hand, @YLG80 compiled this little "Hello world" program to see if any comms were going through but, as far as I could test, nothing went.

It's good to have more people trying to play with this cpu, @zmeura...

Best regards.

Hi,

I have a box with an OMEGA STi5517SWA chip onboard and am having similar problems to the above both with a buffered Jtag and a proper STi jtag/DCU unit.

The pinout i'm using for Jtag is identical to the STi5516 chip and this get me as far as being able to read the chip Id. No problem there !

However, as soon as I try and use the DCU then I get a similar result to some of the above posts. The return is pretty much always (with a very few exceptions) all 00's or all FF's. The exception seems to be that I can read a few processor registers and it looks like they may have sensible values (hard to tell though - could just be random values). The proper STi Jtag/DCU unit tends to disconnect as soon as you try to use it as it fails to change the DCU control register in order to stall the processor.

The buffered Jtag goes further although its obvious its having the same problems. Its just not too bothered about the errors.

When I stick the scope on the TDO pin of the processor, you can see that it goes into 3-state mode almost immediately you try to put the processor into DCU mode. Thats why either 00's or FF's are returned, its just whatever logic value is lying around. You can flip the value returned by briefly touching the pin to 3.3v or Gnd to confirm.

This behaviour seems to indicate the device is not properly accepting entry to DCU3 mode which sort of leads me to believe that either the command sequence has changed, something else is needed or the device had been DCU disabled somehow.

Anybody any thoughts ?

I would try dumping the flash with jkeys.
And don't forget, that program is almost 10 years old now.
Sometimes you are better off with an older version of windows on a slower pc.
The first versions of the sti5105 jtag had to be run on a 700mhz pc or slower,
as an example.

Make sure you are using pin17 on the jtag instead of the standard pin19.
I wasted many weeks on that mistake with the sti5105 jtag program.

Jkeys does very litttle except Id the processor. Even a manual dump only produces a file full of 00's or FF's. As I said above, the jtag pins simply go into a 3-state mode when a DCU transfer is initiated.

The ST Jtag i'm running is a proper Micro-Connect DCU3 unit. Its only a couple years old so should be designed to run with these processors. It certainly runs fine with later DCU3 processors. It connects to the ST toolset via ethernet using an IP address so parallel port configuration or PC speed shouldn't enter into it. This unit simply aborts with an error when connected to this particular chip. Apparently it cannot manipulate the DCU registers so it just gives up. (Checking on the scopt and yes, the TDI output is still in 3-state mode).

For the buffered Jtag using parallel port, i've been through testing on quite a few PC's ranging from an old 66Mhz 486 through various speeds upto 2.5Ghz. Results are pretty much identical regardless so i'm convinced its not a PC speed problem.

Pin configuration makes no real difference. On the ST unit its connected as per the manufacturer recommendations. On the buffered Jtag i've tried just about every configuration you or anybody else has ever mentioned but results are pretty much always the same. Except for the chip ID, the output stays in a 3-state mode.

Initially, I thought the driver on the chip TDO output might be broken but its exactly the same on a further two boxes tested.

There's definately something preventing access to this chip. Perhaps initiating DCU mode requires some kind of "key" or some other register manipulation.

(Checking on the scopt and yes, the TDI output is still in 3-state mode).

Type: The TDI should, of course, have been TDO

For some reason, cant edit the post to correct.

You have to highlight your post then hit edit.
I don't know what program you are running so I can't really comment further.
For the sti5105 I had to make my own .lku file to run under the st20 toolset.
It would only erase/program,I relied on jkeys to do the dumping.
It was mentioned the sti5517 has some kind of security to foil pirates.

Hi guys.
Boxy wrote:

QUOTE:
[...] However, as soon as I try and use the DCU then I get a similar result to some of the above posts. The return is pretty much always (with a very few exceptions) all 00's or all FF's. The exception seems to be that I can read a few processor registers and it looks like they may have sensible values (hard to tell though - could just be random values). The proper STi Jtag/DCU unit tends to disconnect as soon as you try to use it as it fails to change the DCU control register in order to stall the processor. [...]

Which registers are you able to read, @Boxy? Can you post a screenshot so I can compare with mine, pls?
Boxy wrote:

QUOTE:
[...] When I stick the scope on the TDO pin of the processor, you can see that it goes into 3-state mode almost immediately you try to put the processor into DCU mode. Thats why either 00's or FF's are returned, its just whatever logic value is lying around. You can flip the value returned by briefly touching the pin to 3.3v or Gnd to confirm.

This behaviour seems to indicate the device is not properly accepting entry to DCU3 mode which sort of leads me to believe that either the command sequence has changed, something else is needed or the device had been DCU disabled somehow.

Anybody any thoughts ?

I wish I had anything to add but I don't. I'm only starting on JTAG access and still trying to understand how things work but I agree that something might be missing...

Best regards.

Hi guys.

From what I can understand, we're able to control DCU by writing into its registers. So far, all peeked messages we got were either 0x00000000 or 0xFFFFFFFF. Doesn't this mean that we're getting no message at all (I'm repeating what @Boxy said, I know...)? If this is so, couldn't it mean that the target isn't allowed, somehow, to communicate with the host? Are the TARGET_PEEK_ENABLE and TARGET_POKE_ENABLE activated by test compilation?
Sry for all these beginner questions, that you all know the answer...

Best regards.

Hello,
Unfortunately, as you cannot have full access to the registers through JTAG, you have no control on the DCU_CONTROL register bit 7 and Bit 6.
These bits could be disabled if IN_TRAP is set. (see my previous post on IN_TRAP)
So the test compilation cannot change these bits.
This is not a compilation problem.
I've executed that 5517 test compilation on my STi5105 board and the first few peek and poke were returning consistent values.

After reading the CPU ID, the JTAG program (JKEYS or others) needs to setup the tap interface in BYPASS mode which does not happen with your board, likely beacause there is a protection against JTAG.

But if you look at the stburner that comes with the sti5517 toolset,
it has a readfile function in the menu for reading the flash to pc
like our old sti5518 stburner .lku's
That toolset was specifically for the sti5514/16/17 so it must be doable.
If the sti5517 was protected from reading ST would have left the stburner
out of the toolset one would think.
There is a guy selling a blackcat usb jtag cd/cable on ebay and he claims
it does the sti5516/17 processor.This is probably a scam because that program
is geared to cable modem processors.Do a google search for blackcat sb5120

A chunk of that file included in the sti5517 toolset stburner files.
It shows the readfile function is available.

Code:

/*------------------------------------------------------------------------- * Function : ReadFile * Read HEX file into memory * Input : * Output : * Return : File size * ----------------------------------------------------------------------*/ U32 FLASH_ReadFile( char *Filename ) { long int HexFile_p; /* datafile descriptor */ long int HexFileSize; /* size in bytes of the file */ /* Open and Read file into memory */ HexFileSize = 0; HexFile_p = debugopen(Filename, "rb"); if (HexFile_p < 0) { STTBX_Print(("Error opening file \'%s\'\n", Filename )); } else { HexFileSize = debugfilesize(HexFile_p); /* allocate File data buffer */ FreeFileDataBuffer(); FlashData_p = (char*) memory_allocate( SystemPartition, (U32) HexFileSize ); if ( FlashData_p != NULL ) { STTBX_Print(("Loading \'%s\' into memory, wait .. ", Filename )); debugread(HexFile_p, FlashData_p, (size_t) HexFileSize); STTBX_Print(("%d bytes\n", HexFileSize )); } debugclose(HexFile_p); } if ( HexFileSize > 0 ) { /* convert buffer to binary and resize memory */ STTBX_Print(("Converting file in memory, wait .. ")); FlashSize = ConvertMemory( HexFileSize ); STTBX_Print(("Now %d bytes\n", FlashSize )); if ( FlashSize > 0 ) { FlashData_p = (char*) memory_reallocate( SystemPartition, FlashData_p, FlashSize ); } } if ( FlashData_p == NULL ) { STTBX_Print(("Not enough memory for HEX file\n")); FlashSize = 0; } return( FlashSize ); } /* end of FLASH_ReadFile */

I'm still questioning myself on the reason why the CPU pinout on their board is different .

I've checked that readfile routine, but, to me, it is used to read the file from the PC.

They should try to use that 5517FTACI.
The stburner_bak directory can be compiled with no error.
The other directory (stburner) generates some errors, but I've not taken the time to check why.
In the stburner directory, there are additional routines in the main.c : flash WPen, device ID check etc ..