I started a new thread to keep this clutter out of the other DRD435 hacking thread that has turned into a flaming thread. (I know, I had a part in that...)

I have several DRD435 receivers but I decided to work on the one that did not have support from jKeys 2.9.11's definition files, which would force me to learn a little more by adding it myself.

BTW, that version of jKeys is required for the DRD435 and can be found in the Echostar files section on DSS Mili's FTP site.



OK, so I have this funky FLASH chip. Grabbed the datasheet, began comparing the information to a known, working Flash in the jkeys.def file.

Here's my findings so far:

32Mbit FLASH, just like the others we've found in DRD42x/43x
Device Code 8822
32 Sectors of 128KBytes each

From the "FLASH and IRD definitions.txt" file (found in some jKeys .zip files), the IRDFlash needs to be defined as follows:

IRDFlash, 1, "Flash 1(29F400)", 0x2223, 0x7FF80000, 0x80000, 2, 2, 0

Where:
IRDFlash Indicates the line is an IRD definition
1 References the IRD definition from earlier in the file
"Flash 1(29F400)" Name of the flash
0x2223 Flash ID from datasheet
0x7FF80000 Absolute memory starting address
0x80000 Size in bytes
2 Data Width of flash in bytes
2 Data Delta of flash in bytes
0 Data Offset of flash in bytes


OK, everything there makes sense, except for the following:

Absolute Memory starting address - How is this determined?
Data width, delta, and offset - How are these determined?


I used values from a similar Flash to come up with this line:

IRDFlash, 15, "Flash 2 (M58LW032C)", 0x8822, 0x7FC00000, 0x400000, 2, 2, 0



Now on to the more detailed definition of the flash...

Flash definitions identify the Flash ID and associated programming algorythms and memory structure. The following is the definition is used for a 29F400BT

Flash, 1, "29F400BT", 0x2223, 0x80000, 1, 1, 0, 1, 11, 1

Where:
Flash Indicates the line is a Flash definition
1 Unique, sequential Index number used for referencing sector defs
"29F400BT" Name used to represent the flash
0x2223 Flash ID, or device code (found in the datasheet)
0x80000 Flash size in bytes, represented as a hax number
1 8 bit data width possible, 1 - TRUE, 0 - FALSE
1 16 bit data width possible, 1 - TRUE, 0 - FALSE
0 32 bit data width possible, 1 - TRUE, 0 - FALSE
1 Flash algorythms, 1=used by 29x flash,2=used by 28x flash
11 number of sectors
1 Whole flash erasable (not sector by sector ), 1=TRUE,0=FALSE

Sector information is also in the "FLASH and IRD definitions.txt", I won't go into it here.

I'm not sure what the algorythms are for exactly, perhaps someone can explain that? I guessed and used 2 because this is a 58 chip...

With some comparison of existing data, I came up with the folloing lines for the M58 flash chip:

Flash, 22, "M58LW032C",0x8822, 0x400000, 1, 1, 0, 2, 32, 0
Sector, 22, 32, 0, 0x20000 // 128 KByte 32 Sectors


I then saved the jkeys.def file and tested it out in jkeys 2.9.11.

When opening jKeys, it correctly identifies the Microprocessor as STi5516FWB-X.
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.

Everything looks OK!


Now this is where things blow up in my face. I click on "Flash Programming", then OK on the warning. jKeys tries to set the trap and gives a flash codes not recognized error. It says the Mfg/Device codes returned are 20/3A (JDEC) (same for flash file). If I try changing some to the options on that screen and pressing detect again, it always goes back to FFFFFFF flash codes detected.



Anyone have some ideas?

Originally posted by dssseller0001
When opening jKeys, it correctly identifies the Microprocessor as STi5516FWB-X.

This is a TAP identify operation which does not rely on the flash definitions.

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.

This uses the DCU READ operation which does not rely on the flash definitions (except maybe the start address and length).

Now this is where things blow up in my face. I click on "Flash Programming", then OK on the warning. jKeys tries to set the trap and gives a flash codes not recognized error. It says the Mfg/Device codes returned are 20/3A (JDEC) (same for flash file). If I try changing some to the options on that screen and pressing detect again, it always goes back to FFFFFFF flash codes detected.

The first 4 bytes of the flash dump are 00 20 00 3a. If you get flash ID 0020/003a, it means that the flash chip is still in array mode after jKeys has tried to put the flash in identify mode. This is bad.

You will need to read the flash chip's datasheet and try to figure out why it is not entering identify mode. Use the development panel to test various possibilities, word sizes, etc. It's probably in 16 bit word mode but there's no guarantee. Also check your EMI registers. I think one of them should look something like 1699... to enable bus writes to the flash.

Also it's possible that a different command set will be needed for erasing and programming. I know nothing about this flash chip; it is only a wild guess based on the fact that the identify command did not work the same as on the Intel unit.

If you find command sequences that work, well, I guess you'll have to talk to D2 about adding support for them, because you can't patch the jKeys source code yourself.

If the IRD is rebooting on its own at any point during this process, it is likely that the problem is due to operator error when jKeys is attempting to load the trap.

[glenrr]

From the datasheet:
.................................................. .................................................. ..
The Common Flash Interface is a JEDEC approved,
standardized data structure that can be
read from the Flash memory device. It allows a
system software to query the device to determine
various electrical and timing parameters, density
information and functions supported by the memory.
The system can interface easily with the device,
enabling the software to upgrade itself when
necessary.
When the CFI Query Command (RCFI) is issued
the device enters CFI Query mode and the data
structure is read from the memory. Tables 26, 27,
28, 29, 30 and 31 show the addresses used to retrieve
the data.
.................................................. ..................................................
Which reads the same for the m28w and m29w, so why won't it work for the M58??

Originally posted by glenrr
From the datasheet:
.................................................. .................................................. ..
The Common Flash Interface is a JEDEC approved,
standardized data structure that can be
read from the Flash memory device. It allows a
system software to query the device to determine
various electrical and timing parameters, density
information and functions supported by the memory.
The system can interface easily with the device,
enabling the software to upgrade itself when
necessary.
When the CFI Query Command (RCFI) is issued
the device enters CFI Query mode and the data
structure is read from the memory. Tables 26, 27,
28, 29, 30 and 31 show the addresses used to retrieve
the data.
.................................................. ..................................................
Which reads the same for the m28w and m29w, so why won't it work for the M58??

The CFI data structures have nothing to do with it. Clearly this chip is stuck in array mode in an instance when the user does not want it to be.

Are you sure that jKeys is issuing the read ID command in a fashion consistent with the product specs? Again, time for some guesswork or port logging because we have no source code. And we still have not ruled out operator error either.

It's easy to write a piece of software that works correctly on "most" flash chips, but the fact of the matter is that once in a while some manufacturer does things just a little bit differently and the scheme backfires on you. This might or might not be an instance of that.

[sdeens]

check the files section, looks like MrWhite just uploaded the proper jkeys def file for this different flash chip found inside the RCA435

once it clears moderator review it just might solve your problem

good luck keep us informed how it worked and if the firmware is 100% identical to the RCA435 that uses the Intel E28F320 chip..my guess is, it probably is, but just want to make sure.

[sdeens]

http://id-discussions.com/vbulletin/...threadid=63321

The file that was uploaded by MrWhite is INCOMPLETE! It is missing the actual flash definitions that I made in the first post.


Mine works now! Woo-hoo!

I inadvertently set the flag that tells jKeys that the device is 32 bit wide capable.

I have it right in my original post, but somehow I messed up on the actual file. (Translation: FAT-FINGERS)


OK, now to continue...

With the DRD43x (not 435) receivers, Blaknite was gracious enough to give me to commands needed to manually allow FLASH writing. (CPU gives the flash 3.3v on the enable pin.) I still haven't figured out how he got that information from the data sheet, but I'm determined to figure it out.

On the DRD430, you simply go into the development panel and put in the following under Memory/Misc Access:

Address: 2000e030
Data: FF

Click on Write Word, then enter:

Address: 2000e000
Data: FF

Check the light on the front of the receiver and it should be on.

Now you can go erase & re-program without having to manually apply the power.


So, for the M58LW032C chip, how are the correct commands determined to tell the CPU to enable writing on the flash?

[sdeens]

The same trick used on the RCA420, but what I don't understand is why you want to use the developmental panel trick to enable flash programming when 3.3 volts has proven to work flawlessly on the RCA430 models.

Are you suggesting this is a better method and how does this apply to the M58 chip found in the new 435's, which is what I thought we were discussing?

[sdeens]

and yes i also noticed that he did not include a specific flash definition for the M58 chip..he stops at flash definition #20.

are you saying you made a small change in the flash programming window to allow it to correctly identify and erase the M58 chip using Mr white's existing file?

The same trick used on the RCA420, but what I don't understand is why you want to use the developmental panel trick to enable flash programming when 3.3 volts has proven to work flawlessly on the RCA430 models.

I know that method works, it's just a pain to have to manually add the power when I can do it from the development panel using the CPU's built-in method.

I also like to use the CPU to do it so I can leave the FLASH unprotected to observe behaviour and easily make changes.

and yes i also noticed that he did not include a specific flash definition for the M58 chip..he stops at flash definition #20.

are you saying you made a small change in the flash programming window to allow it to correctly identify and erase the M58 chip using Mr white's existing file?

No, the changes must be made in the jtag.def file. I'm not sure why they are missing in MrWhite's uploaded file.