pcmhacking.net

Same clip same settings.
Just the last few writes seemed to have changed only a few lines at a time.
The only thing that I did was try a different bin file and after each write it seemed to fill in a little more each time. Maybe there is a bad connection somewhere but i checked with a multimeter and nothing seems to have a loose or bad connection.

Will post back when I have a bit more of a play with it.

Hoping that somebody might be able to trouble shoot this 1 both pictures are of 2 different bin files that I have read the top part shows what is being read back and the bottom part shows the orig file Now I know the 2 files on each picture are different but I dont think they are that much different.
With the top picture each spot that had E1 has been replaced with C3, then 81 with 03 and so on. The bottom bin file is doing the same thing also.
Maybe I have a setting wrong on my programer or the only other thing I could think of is maybe lifting the leg of the Vcc and see if that helps.

Whats the part number of the chip? Looks to me like you may have the wrong one selected and be reading and writing straight off the end of the data area. Try chopping your bin down to 128 bytes and writing, you could be corrupting it if you are overrunning in to no mans land.

2BD0 rotate left w/carry = 57A0, E181 rlc = C303, so I'd assume it's not coincidental...
I haven't been following the thread, but it's an SPI chip you're writing to isn't it? Edit: I saw you're writing at +1 speed, drop it down to the slowest possible until it's working properly.
I noticed the 00 00 is coming out as 00 01, which coupled with the 2BD0->57A0 issue looks like you're getting an extra bit in there somehow? An extra clk pulse, or possibly an edge/level issue? SPI can be a bit tricky with all the different "standards"

The chip is correct and had another member look at the bin file and he confirmed that the read was clean.

Yeah have been trying at all speeds will try with slower speeds again, it seems to come out with the exact same result from the max speed to the slowest speed.
I just tested the Vcc and when it is writing it maxes out at 3.61 volt. I am running a external 9v power pack with the gq-4x programer.

It is a little frustrating as I feel it is close to working but just not close enough yet

Looked a bit closer, and I think it might be a software error.

Compare DC:DD - FE:21 (read) and FF:10 (orig)
That's: An FF in at an odd offset is written/read correctly (but not when at an even offset) and 00 in an even offset is correct but not in an odd offset .

From the datasheet:

Address bit A7 is not decoded by the M93S56

If the software was sending 8 bit addresses then could the last address bit be being taken as the first data bit?

the voltage isn't a problem as they operate between 2.5 and 5.5 volts

i don't think these 93s56 like being written to while connected and your programmer is writing 01 in locations for some reason, that cluster won't work properly as it has messed up all the stepper motor calibrations and cluster programing values.

you need really good clean connections

kody wrote: Maybe I have a setting wrong on my programer or the only other thing I could think of is maybe lifting the leg of the Vcc and see if that helps.

I would have thought lifting the vcc leg would do the trick. Since wouldnt be losing power would you?.

madmn wrote:you need really good clean connections

As madmn said, dont think its possible to do the writes on board. No-one has been successful as of yet!

Lifting the Vcc leg did not help, I am really starting to think that it cant be written to on board but can be read.
I also updated the GQ-4X software but that did not help, also tried at every speed with no improvements.

I guess i'm going to have to give this a go but, in the mean time since i don't have a VT cluster, can someone short the resonator crystal and then try to write to the eeprom without powering the cluster it self.

i think this maybe be the cause of the timing issues