I am skeptical of that one,since the 5516/5517 are dcu3 devices you would never
hit the flash programming button.You would just set the correct address/size
then hit the save mem button.

Hi guys.

I also saw that topic @YLG80 and I'm facing the same problem that romeok01 is.
From what I could find on flash's datasheet looks like 0x80 is the address of the protection register. Wouldn't it be possible to write to this address with jKeys?

@slugworth, when I click on "Save mem" I get "Error reading from memory" and the saved file with 0 bytes.
If I try the method they mentioned on the topic I get:

Best regards.

I don't know if the sti5517 has a bfr pin like the sti5518 that sometimes has to be
grounded even to read reliably.I would have to look at the pdf for it.

I don't think you will be able to write in that register if you cannot setup the Diagnostic Controller.
On solution would be to establish a ucTAP connection with the ST20 Toolset.
But it means compiling an application with the Toolset.

Hi guys.

@slugworth, don't know either and only have the STi5516 datasheet...

@YLG80, that's something that also crossed my mind: - getting ucTap to have this done. As for compiling an application with the toolset I lack all the knowledge to do so, although really keen on learning if someone wants to "waste" some time on making me understand.
One question, if I may: - will I be able to use ucTap to read or is it a "write only" app? I ask this because that's the idea I got from what I read on the web...

Thank you both guys.

Best regards.

Normally the 5517 is pin to pin compatible with the 5516, if I remember.

With the ToolSet, you can do whatever you want.
If you compile a flash program you can read, verify or write.

The first thing is to setup the Diagnostic Controller (DCU3 in that case) so that you
can enter in debug mode. As you have full control on the CPU you can do whatever you want.
But it's not really simple because it means programming. Fortunately there are many program samples that can ne used as a basis. I gues the flashprog utility that we have used for the Sti5015 could be recompiled for the 5517 but we would need to change the routines for your specific flash chip.

I've not found the 0X80 register in the 5516 datasheet.
I'm wondering how they could protect the flash from being read.
At least during the first boot stage, the CPU needs to read the flash prior to copy it into RAM.
After a complete boot, the CPU could force the flash chip into reset mode without any problem, because it runs now in RAM.
This is the reason why I've asked you to try to launch Jkeys upon reset.

..and good news, the M58LW032 is described in st_flash.c and tt_flash.c source !
(to examples for flash programming)

Code:

elif defined(mb361) /* mb361 */ #define DEVICE_TYPE STFLASH_M58LW032 #define MIN_ACCESS_WIDTH STFLASH_ACCESS_16_BITS #define MAX_ACCESS_WIDTH STFLASH_ACCESS_16_BITS

the mbxxx are development boards for which there are configs and routines available in the ToolSet: parse "include dcu_mb361.cfg\n" ## STi5516 parse "include dcu_mb382.cfg\n" ## STi5516/17 So in your case the mb382 could be used together with the M58LW032x. However I don't remember if we were able to recompile that source. I will check in the laptop where I've stored all that stuff.

schematic of the echostar dp311 showing a sti5517 processor

Hi guys.

Nice one.

I didn't get why you were looking for the 0x80 register in the STi5516 datasheet; when I mentioned it I was referring to flash's registers (I got mixed up... ).

OK, so what shall I do next? Get the ST20 ToolSet in order to be able to compile for this IRD and flash (after the needed changes)?

Best regards.

jkeys first,no st20 toolset program ever let you save flash.

Hi guys.

OK. I'll be here for whatever is needed.
In the meantime, I go and read some more about DCU3...

Best regards.

My mistake, was looking for the 0x80 register in the M58LW032 DS. Sorry.

As test for the pdf upload :
I've changed the settings and added various file types (.hex,.bin,.pdf.rar)

From the M58LW032C datasheet:

QUOTE:

The Reset/Power-Down pin is used to apply a
Hardware Reset to the memory and to set the device
in power-down mode.
The device features an Auto Low Power mode. If
the bus becomes inactive during Asynchronous
Read operations, the device automatically enters
Auto Low Power mode. In this mode the power
consumption is reduced to the Auto Low Power
supply current.

In the pin description

QUOTE:

After Reset/Power-Down goes High, VIH, the memory will be ready for
Bus Read and Bus Write operations after tPHQV. Note that Ready/Busy
does not fall during a reset, see Ready/Busy Output section.
In an application, it is recommended to associate Reset/Power-Down pin, RP,
with the reset signal of the microprocessor.
Otherwise, if a reset operation occurs while the memory is performing an
Erase or Program operation, the memory may output the Status Register
information instead of being initialized to the default Asynchronous
Random Read.

I guess this could be the reason why you cannot read the flash.
If possible you could try to disconnect the Reset Pin from the main circuit and connect it to the jtag nRST pin.
It could be very difficult if your chip is of a BGA type.

Mornin' to you guys.

You definitely make sense @YLG80...
Right now, I have these connections (refer to post #48):
DB25-----PCB
2<------->tms
3<------->tck
4<------->tdi
5<------->reset (previously ntrst)
12<----->ntrst
13<----->tdo
25<----->gnd
I don't really know how jKeys works but looks to me that the app must get DB25/5 low in order to start the whole process. After what you said, I assume that the PCB reset point should be an output to reset flash and cpu.
I can try to find someone who has already taken out the cpu and try to follow this track...
Like so, we'd still get problems even if we compile an app with the ToolSet, don't we? We first need to sort out the flash issue, so we can carry on...

Best regards.

What type of Flash chip do you have : a TSOP (with pins around) or a BGA with pins below.
On the ST Toolset, Slugworth is right : up to now we have no application that can dump the flash to a file. Only verify, erase and flash.

Normally with a TS application we would not have the same problem with the locked flash chip, as the program takes complete control on the CPU upon reset and enter in DCU3 mode. This prevents the STB to enter the first boot stage.

In normal mode,I guess your flash chip is placed in reset/low power mode at the beginning of the second boot stage, when the program continues from RAM.
This would mean the flash reset pin is likely connected to a CPU PIO output.
Disconnecting the reset pin from that connection and reconnecting it to the main CPU reset pin would resolve that issue.

One thing to try : modify your interface as for ucTAP (pin 17 and 19) or build the simple interface for ucTAP and try with jkeys immediately after the STB power up.
When, I do this here, I 've seen that the STB cannot boot as long as jkeys is running.(Led is off while jkeys is running and on after shutting down jkeys.
As soon as you shutdown jkeys, the boot continues.

Hi again.

I have a TSOP flash.
Right, I think the way I have my interface now is the ucTAP way (nRST is on db25 pin 5 instead of nTRST which, on its turn, is on db25 pin 12).

The test: - as far as I could find out, I don't get the same behaviour you do, @YLG80. Actually, looks like I get the opposite. When I start jKeys right after powering on the board, the led behaves the usual way (stays off for few tenths of seconds, then comes on for ~1 sec, goes off again and back on right after). If I click on "Detect" when power is on, I get exactly the same behaviour.
One thing though, when I close jKeys, led goes off and stays this way until I restart jKeys or power off and back on the PCB. Right now, jKeys is not running (I closed it), power is on and led is off. Makes me wonder... Is this working the other way round?
Hope I expressed myself enough so you can understand...

Best regards.

I will have to try on my STB, but that will for tomorrow as I have to leave in few minutes.
This is the wiring for ucTAP

Even if you use a buffered jtag interface, you should swap certain pins in order to have the same connections between the DB25 side and the JTAG side.
I use the PCBWIRE-MULTI JTAG (buffered) and I had to swap pin 17 and 19 and add the missing connection from DB25 pin 12

Hi there.

No worries @YLG80, have a nice time...

For the ucTAP wiring, the one you posted is the one I checked mine against. I use a passive jTag (only resistors), no buffered one.

Will talk tomorrow.

Best regards.

Thanks to you I've verified that my JTAG connections and TS programs are still OK.

You are right on the power LED behaviour when the interface is wired for ucTAP.
In fact the behaviour I've described is for the LED display, displaying Load, Boot, On, Init Menu and channels.
When no jtag program is running, my STB boot is blocked with nothing displayed when I power it ON (black display).
When launching ucTAP the STB remains in the same status.
However when launching JKEYS, the boot continues up to the end.
If I click on the JKEYS Detect button, the STB reboots. (after a reset)

Prior to use any TS application with ucTAP, I need to reset the STB again.
Then any Toolset application is running fine.

So your flash is a TSOP.
If you are good with a soldering iron, you could carefully desolder pin 16, isolate it from the pCB pad and reconnect it to the main reset with thin wire wrapping wire.

Prior to do that type of surgery, you could trace the PCB track that goes to that PIN. It would be easier to have only to cut the track connected to that RP pin.

Hi guys.

Yes, I was talking about the power LED.

I could lift up flash's pin 16, no worries (done that before in other equipments) but I have a short track connected to this pin, before it disappears via a through hole (multilayer...), so I'm thinking of following your 2nd suggestion.
Before I do that, what do you think about checking first if this pin goes low whenever jKeys starts or "Detect" is clicked, so we can pinpoint this is what prevents the flash from being identified?

Best regards.