Drd420re

[usbbdm]

Same result - see my addition to prev post.

I'm begging you to explain each mode - without the knowledge we are shooting in a dark.

Also, there no indication what algo is using, perhaps the parameter is taking into process , we don't know. May be I can send some cmd to check what algo is using currently ?

After about 6 years you are the first person who ask this questions. I have to dig into the code and find out myself. As I said the EEPROM algorithem is the same as Dave 2. You said Dave 2 has good explain on the EEPROM. Then you should know which value it is.
I do not have your box to test and thus hard to help.

You only need to know the right value of EEPROM protocol.

If the second read is off, there might missing init code and then you might need to power off/on again.

[usbbdm]

The mode of the EEPROM is the routines for different CPU. Different register/memory to play. This has been done about 6 years ago. Not a lot people ask for it.

I am more interested in new dish boxes that uses EEPROM (Like Sonicview or CNX Nano arm core).

In the future the EEPROM algo will be an external file (instead of 0,1,2,3). That way it is easy to add new boxes with EEPROM.

More work spent on DCU3 and ST40 core. Very few people play with ST20 now days.

[JTog]

Well, the box is still interesting to play with its guts.

I think I got the reason for the bug.

There is different commands/addressing bytes in serial EEPROM if size is bigger.
Your algo(s) perhaps working with fixed length 0x800 hence quadruple of same content.
When you'll update your program, please be sure it will support up to 24LC512, what newest boxes using. Also I've seen in some devices serial EEPROM what holding whole FW - 8 Mb chips - as images of squashFS and others types.

As to timing and other parameters of I2C bus (not the serial EEPROM itself), IMO they should be limited to two variants: bus speed 100 KHz and 400 KHz. I don't think users should go into set timings, as it adhere to standard of I2C.

And please, while you're looking into you old (6 years) source code - bring usable description for all modes, perhaps I'll finally get reading/writing the damn serial EEPROM inside of the 420.

Oh, forgot to ask: what the parameter mean for serial EEPROM <Address>0x0</Address> ?

And another observation: while I did play with the box, I found the USBJTAG interface sometimes required to reset; I don't have information how to do that, so I just disconnect/reconnect USB cable to it. Symptoms for the necessity of the jinxing - IDCODE become 0, it happened many times, so I got to use it, sometimes no reason for the issue - program is running, box is still running, just reading flash/otp/eeprom randomly multiple times and oops getting ID=0.

[usbbdm]

Well, the box is still interesting to play with its guts.

I think I got the reason for the bug.

There is different commands/addressing bytes in serial EEPROM if size is bigger.
Your algo(s) perhaps working with fixed length 0x800 hence quadruple of same content.
When you'll update your program, please be sure it will support up to 24LC512, what newest boxes using. Also I've seen in some devices serial EEPROM what holding whole FW - 8 Mb chips - as images of squashFS and others types.

As to timing and other parameters of I2C bus (not the serial EEPROM itself), IMO they should be limited to two variants: bus speed 100 KHz and 400 KHz. I don't think users should go into set timings, as it adhere to standard of I2C.

And please, while you're looking into you old (6 years) source code - bring usable description for all modes, perhaps I'll finally get reading/writing the damn serial EEPROM inside of the 420.

Oh, forgot to ask: what the parameter mean for serial EEPROM <Address>0x0</Address> ?

And another observation: while I did play with the box, I found the USBJTAG interface sometimes required to reset; I don't have information how to do that, so I just disconnect/reconnect USB cable to it. Symptoms for the necessity of the jinxing - IDCODE become 0, it happened many times, so I got to use it, sometimes no reason for the issue - program is running, box is still running, just reading flash/otp/eeprom randomly multiple times and oops getting ID=0.

That definitely explains why. When EEPROM size is small, the address uses two bytes. When EEPROM is bigger it uses three or 4 bytes of address.

I will not fix this issue sine I do not have this box to play with. In the future this will be an external data (similar to dll) that will be loaded if the xml needs it.

[JTog]

That definitely explains why. When EEPROM size is small, the address uses two bytes. When EEPROM is bigger it uses three or 4 bytes of address.

I will not fix this issue sine I do not have this box to play with. In the future this will be an external data (similar to dll) that will be loaded if the xml needs it.

You don't need the box - I have the box to test, you have all the specs for correct the bug.

Please help to fix the program.

[JTog]

Oh, forgot to ask - is there any plans to add Device Debugging (remember jTango ?).

[usbbdm]

Oh, forgot to ask - is there any plans to add Device Debugging (remember jTango ?).

What is that? This JTAG is not based on any other program.
What is Debugging mode you are talking about? ST20 is long gone and there should not have a lot of development for that.

[JTog]

ST20 is not dead, yet and using in many working boxes. Old good horse ...

I'm not telling about your base, I'm reminded you about other development (from days of jKeys) - jTango to debug/trace programs using JTAG, what is main purpose of JTAG interface, not the stub feature - reflash chips.

[usbbdm]

ST20 is not dead, yet and using in many working boxes. Old good horse ...

I'm not telling about your base, I'm reminded you about other development (from days of jKeys) - jTango to debug/trace programs using JTAG, what is main purpose of JTAG interface, not the stub feature - reflash chips.

In that case, I think NT has what you need. It can peek/poke memory.

Type "help" for the complete command sets.

[JTog]

You should really try jTango ...

PEEK/POKE is good, but it's not a tool for debugging.

[usbbdm]

I have implemented some DEBUG function for MIPS. That is called ICE. Check dct700.xml. Not for ST20.
In fact there once talk about adding GDB support but get stopped due to lack of interest.

[JTog]

I need get back to the 420 support ... and ST20 debugging.

If you need the board I can give it to you, or I can help do whatever need to be done: SW development, debugging, etc.