-
Why 10ms delay is huge?
If it needs a week then it takes a week.
Reading subroutine starts from line 440 and its loop from 452.
461-464 is putting the address out.
There you have the first 4tcy delay.
466 changes the direction of a port, I guess.
467 has the next delay.
484 then is the actual read.
From pgm_common.c
uint8_t pgm_read_data(void)
{
#ifdef _M8OD
return (uint8_t)cpld_read(PORTC);
#endif /* _M8OD */
#ifdef _MDUINO
return DATA_PIN;
#endif /* _MDUINO */
}
Indented lines are actual read commands.
One for _M8OD and other for _MDUINO.
So despite all your pre read delays you're still actually reading like zap, it's done.
You should replace that 484 line with your own reading procedure.
Address is there and is not changing so you can read as many times as you like.
Maybe you should read 100 times and analyze what you get.
You can replace that 484 line with how ever more stuff also, so you can put there read, delay, read, delay and so on.
Maybe you should modify the board and read using analog pin.
If you have only one analog pin then probably easiest is to read one bit thru the chip and then manually connect it to the next bit.
Though it's probably not helping with weak output.
Thanks for the input!
Could this be done without too much change in the code?
«Quasi-basic»:
10 write address to mcu
20 delay to let mcu latch them in
30 read the eight bits
40 delay
50 read the same bits once or twice more with delay between
60 compare the bytes
70 if different, goto 30, else next address -
A quick&dirty 2-of-3 majority selector with infinite retry:Code: [Select]
uint8_t pgm_read_data(void)
{
while(1)
{
_delay_us(20);
uint8_t d0 = DATA_PIN;
_delay_us(20);
uint8_t d1 = DATA_PIN;
_delay_us(20);
uint8_t d2 = DATA_PIN;
if (d0==d1) return d0;
if (d0==d2) return d0;
if (d1==d2) return d1;
}
}
You can change the conditional part to a singleCode: [Select]if ((d0==d1) && (d0==d2)) return d0;if you want all 3 samples to match. -
Amazing!
Now we are getting somewhere, while learning a bit of code too!
Thanks a bunch.
I'll update as soon as I have time to implement this (busy times ahead...) -
abyrvalg's code is data level independent when your case is not.
Since your software situation is limited you should try to analyze dumps more.
Like reading 10 times and then comparing them all.
Can you somehow deside how the data is bad.
It can be many things form many angles.
Stressing output first is probably a good approach, so that all 3 match can be the first "if" but after that there should be something else.
You can also fiddle with those delays if you feel a need.
If all 3 are not matching the next thing should be a long delay, to give output stage time to stabilize.
But what then, how can you deside, actually on the fly, how to continue.
If you can construct an idea I'm pretty sure someone will code it for you.
You can also concentrate to bad bits but first you should deside how to generally treat that bad data, like up wrong or down wrong.
Good starting point could be those ascending fillers.
With those 3 reads 1 bad bit can be
001
010
011
100
101
110
4th and 6th can be guessed as up, 5th is a so-so but what about those first ones, can you guess them all being up.
All zeros can still be almost up and you just see them as totally down.
But if the machine is working in the cold I'd check that situation first, including all possible voltages.
Manual says that A.C. tests for inputs are 2.4V up and 0.48V down and output timings at 2.0V for up and 0.8V down.
Also, since the chip is a microController there are possibly no use of data lines in normal operation.
-
Sure, understanding the failure mode instead of guessing could direct to more efficient approaches.
I.e. for marginal depleted EPROM cells the failure mode would be asymmetrical (0 reading as 1 sometimes, but no 1 reading as 0) and a better approach would be to take a logical AND of several samples to catch all 0 states:Code: [Select]uint8_t pgm_read_data(void)
{
uint8_t result=0xFF, i;
for(i=0; i<5; i++) //5 is number of samples, adjust if necessary
{
result &= DATA_PIN;
_delay_us(20); //can be reduced/removed at all and number of samples increased instead
}
return result;
} -
I suggest checking voltages on the pins with oscilloscope. There are failure modes when some pins may not pull exactly to the power rail. So input voltage threshold in reading device can make the difference. EPROM reading threshold is not relevant here since it's a mask ROM.
-
I suggest checking voltages on the pins with oscilloscope. There are failure modes when some pins may not pull exactly to the power rail. So input voltage threshold in reading device can make the difference. EPROM reading threshold is not relevant here since it's a mask ROM.
The problem is that since ground/common is floating on both the laptop and PSU, and my DSO is earth ref., I get sinusoidal waveforms mixed in.
I don’t dare to connect the probe ground/earth in the circuit.
I can see the activity, but meassurements are difficult. -
Norwegians and their floating mains.
Measure something stable with the other channel and invert it, then sum both. -
Measure the earth current via some resistor first, then (if nothing crazy measured) connect directly?
-
The problem is that since ground/common is floating on both the laptop and PSU, and my DSO is earth ref., I get sinusoidal waveforms mixed in.
I don’t dare to connect the probe ground/earth in the circuit.
I can see the activity, but meassurements are difficult.
Why? Common on the PSU and laptop are floating, that makes it safe to connect the scope probe ground clip to that node, a scope is useless without the ground clip connected. I don't understand the thinking that this would be in any way unsafe. -
Norwegians and their floating mains.
If the ground is floating, you just connect the ground clip of the probe to it. It's actually less safe to probe without ground attached since it increases a chance to cause ESD damage to the circuit.
Measure something stable with the other channel and invert it, then sum both. -
I'm not exactly sure what is the complete situation here and what trondl is actually affraid of.
Or why he has dropped in the hole of one wire for all.
Specially if all parts are in front of him on the table.
The suspicious mains mindset is one possibility but it needs old and unknown connections.
Maybe not old in Russia but there also the building should be old, I guess.
Level of "ground" can be many things but if everything is in same space and using the same mains plug there are very little that are unknown.
One new thing though, non metal plumbing.
E,
b -
First of all, thanks for verifying what I _thought_ but didn't _know_ regarding ground references.
Better safe than sorry.
On the other hand though, it may be toast now
I've now tried to power VCC (pin bent out off socket, and common to shield ground) through my DIY psu, first at 4.5V, 5V and 5.5V in room temperature (22 C), with and without a metal bolt directly from the freezer.
The PSU doesn't have current limiting though
What I quickly noticed is that the mcu without cooling got quickly hot (ouch hot) with that distinct warm chip smell, although no smoke.
It was even causing my psu to start sagging in voltage after about a short minute.
After cool down I noticed that VCC was drawing ~30mA at 5V with my DMM in between.
I do now with the "sample 3 times / compare" at least get "stable" readouts, which I didn't with VCC power from the shield (gave timeout error in the HVEPROM app).
Every time giving variations in the read outs.
The bits are mostly 0, with some small repeated burst of 1 in patterns.
In hex, I get values ranging from mostly 00 to 07 (only bits 0 to 2 toggling), and a weird dump that started with repeated F8 and later F9 for the first 16 offsets, then continuing with the 00 to 07 randomness.
Should I even attempt to go 6V, dare I say 6.5V?
I did after the panic had settled, verify that the shield was still intact with the known good 8749.
It was
-
I'd say that you need a second opinion now.
Something where you can put the hadware away for a while.
Make 10 dumps and get a hex editor with compare, HxD is one.
Then check if you can isolate good and bad areas.
You can also compare your dumps to that same producer's other dump and boot code (addr 0) there, with luck all are pretty equal.
First the code is probably jumping somewhere, from address 0.
After that (addr 3) can be an interrupt code jump.
Timer jump can be at address 7.
If interrupts are not used the code can start from address 0.
0 E5h (select memory bank 0)
1 [bbb0]4h (jump ([bbb0]/2)xxh)
2 xxh
is one possible start.
-
The chip getting "ouch hot" is a very bad sign, that should never be happening. Do you perhaps get the polarity wrong and connect +5V from your PSU to Vss instead of Vcc? Did you connect the - output from the PSU to the +5V rail on the board instead of ground, resulting in +10V across the IC? I agree that a second opinion here would be useful, or at least a schematic showing visually how you have tried to hook it up each time.
-
The chip getting "ouch hot" is a very bad sign, that should never be happening. Do you perhaps get the polarity wrong and connect +5V from your PSU to Vss instead of Vcc? Did you connect the - output from the PSU to the +5V rail on the board instead of ground, resulting in +10V across the IC? I agree that a second opinion here would be useful, or at least a schematic showing visually how you have tried to hook it up each time.
I always doublecheck such things. If tiered, triplecheck.
Positive to pin 40/VCC with the pin bent out of socket, and negative to arduino shield ground which VSS is tied to.
I believe that there has been an internal short or lose wire that was remedied by freezing.
The psu in the intended unit was probably not strong enough to heat up the chip, same with the arduino shield.
30mA at 5V would be a rather low resistance, but no direct short.
Another round of freezing temperatures (-10C) is inbound here in Norway.
I’ll give it a second chance, or I’ll toss it in the oven at 150C for some minutes as a last resort. -
Sorry for the very late sitrep.
I had to put it aside to continue on some other projects.
Thought it was about time to see if something could be done again.
And something was observed!
I thought it was about time I did some of the most sane thing to to: compare the waveforms to a working 8749.
This time without a separate PSU for VCC, and in room temperature.
When idle, 8749 gets a clean 5V at the i/o bus and 0V at VCC.
8049 only get about 1.5V at the bus and VCC / VDD is about 1V.
When dumping (with the standard unmodified hex file loaded in the shield), the waveforms on the 8749 are stable with clean pulses and has a distinct beginning and end pulsing of the data stream.
The 8049 on the other hand has a very unstable and fast switching stream, as in hi-lo-hi-lo-hi-lo in the time frame the 8749 would only go hi-lo, and as previously mentioned, "floating" areas of the stream at about 1-2V.
I still get the same semi-random values as before the "ouch" moment with the external psu.
Something seems very wrong here and may explain why I get no valid data.
With a DMM I tried to check if there was a resistance between VSS and the i/o pins, VCC and most of the readings where in the mega ohms if at all, compared to the 8749 in kilo ohms.
Could this indicate that the chip is indeed very dead and is no longer worth the time, considering that I still get the same "values" as before? -
One further observation is that I see in the schematics that there are no pull-up or down resistors on the data bus D0 to D7 (AD0 - AD7).
It's all directly routed to the Arduino.
Could this be an issue?
The "floating" area of the stream may actually be Low bits, but not low enough in voltage (1.5V).
Also the additional address pins P20 to P23 (A8 to A11) all give perfect pulses. -
What are you doing with the PROG pin? Looking at an old datasheet for the Intel 8048/9 series there is a curious note under the programing and verify timing waveforms for the 8048 (I can't see an equivalent for th 8049 - so YMMV), it says:
"Prog must float if EA is low, or if T0=5V for the 8748. For the 8048 PROG must always float." -
Hi again!
Got some update, although not the best kind of update.
Bought an almost cheap second unit from japan in the hope that dumping the second MCU would be a breeze.
Not so.
The dumping waveforms are almost exactly like the failing one.
It just seems like the LO bits never reach ~0V and VCC is also idle at 1.5V, just as the Data pins are doing.
Is this actually a fault on the Arduino or the code?
The Data pins on the shield are directly connected to the Arduino without any pull-up or down resistors (unsure about what to do when trying to help a signal go LO).
I've seen articles about a built in pull-up resistor in the Arduino itself.
Could this be utilized, if not already in the code (if so, where?)
Included screendumps from the DSO:
First: "new" 8049 during a dump on pin D7, second: VCC idle, third: working 8749 during dump, 8749 VCC idle.What are you doing with the PROG pin? Looking at an old datasheet for the Intel 8048/9 series there is a curious note under the programing and verify timing waveforms for the 8048 (I can't see an equivalent for th 8049 - so YMMV), it says:
PROG is HI during the entire dump
"Prog must float if EA is low, or if T0=5V for the 8748. For the 8048 PROG must always float."
-
Do I understand correctly? - the idle Vcc sags from 5V to 1.5V? Looks like there is some pin driven low connected directly to Vcc. Which pins of 8049 are connected to Vcc now? Try disconnecting them one by one while observing the Vcc level to find which one causes the sag.
Andy Watson says “PROG must float” and you say “PROG is HI” - is it floating and driven HI by the 8049 or you drive it HI? That can be the first candidate for disconnect. -
Do I understand correctly? - the idle Vcc sags from 5V to 1.5V? Looks like there is some pin driven low connected directly to Vcc. Which pins of 8049 are connected to Vcc now? Try disconnecting them one by one while observing the Vcc level to find which one causes the sag.
According to the schematics: pin 39 T1, pin 5 /SS and pin 6 /INT / /CS are tied to VCC.
I'll try lifting them later today -
Assuming I am looking at the correct programmer circuit, the PROG pin appears to be pulled HI (via a diode) with a 220\$\Omega\$ resistor - that's quite an aggressive pull-up, especially for a cmos device. I would not class it as "floating".What are you doing with the PROG pin? Looking at an old datasheet for the Intel 8048/9 series there is a curious note under the programing and verify timing waveforms for the 8048 (I can't see an equivalent for th 8049 - so YMMV), it says:
PROG is HI during the entire dump
"Prog must float if EA is low, or if T0=5V for the 8748. For the 8048 PROG must always float." -
When idle, 8749 gets a clean 5V at the i/o bus and 0V at VCC.
8049 only get about 1.5V at the bus and VCC / VDD is about 1V.
...
Bought an almost cheap second unit from japan in the hope that dumping the second MCU would be a breeze.
Not so.
The dumping waveforms are almost exactly like the failing one.
It just seems like the LO bits never reach ~0V and VCC is also idle at 1.5V, just as the Data pins are doing.
Something is very awry, if Vcc droops to 1.5V - Check the current demand ? and compare your 8749 with 8049's
Those old parts are NMOS so they need a lot of supply current
You might also want to check the pin-mapping, to make sure it really is an 8049 ?
-
Something is very awry, if Vcc droops to 1.5V - Check the current demand ? and compare your 8749 with 8049's
Those old parts are NMOS so they need a lot of supply current
You might also want to check the pin-mapping, to make sure it really is an 8049 ?
Thanks a bunch again for all the help from everyone so far!
Things are busy as usual, resulting in slow progress.
Yes, it is definitely a 8049 I'm dumping.
I've attached screenshots from the SDE1000 service manual and the Arduino shield for comparison.
When desoldering the "new" second chip, pin 34 (P1-7) was bent inwards / floating.
No Idea why that specific pin was in that state compared to the other unit I have, where all pins where soldered.
I need to clarify one thing here.
When the 8749 is idle, the only pins that are held high/5V are the DB0-7 pins.
VCC is at 0V then.
The 8049 is when the Ardino is fully restarted at 0V on all pins (even on the VCC and DB pins, but on successive read it seems like it enters a semi-stuck state with 0.9 to 1.5V on various pins (listed bellow).
I repeat that VCC should be 0V, not ~1V when idle.
I've also tried to lift some pins with no direct results: 25 Prog, 5 SS, 6 INT, 39 T1, 11 ALE.
Comparing which pins are absolutely necessary with this other project:
https://www.sbprojects.net/projects/8049spy/index.php
While at it, I made a list of which pins are stuck after a dump.
A curious discovery is at pins 27 & 28 (P1-1 / 2) is tied to ground, while the rest of P1 up to pin 34 is floating and has the stuck voltage.
Would it be safe to tie the rest of the P1 pins to ground?
Could there be more pins that could be tied low instead of floating?
Could VDD be disconnected?
Description:
Pin#, _x_ after pin indicates >0.9V present, Name, Notes in reference to Arduino shield schematics.
1 T0
2 xtal
3 xtal
4 Reset
5x SS
6x INT
7x EA
8x RD floating
9 PSEN
10x WR floating
11 ALE
12x DB0
13x ..
14x ..
15x ..
16x ..
17x ..
18x ..
19x DB7
20 Vss
21 P2-0
22 ..
23 ..
24 P2-3
25x Prog
26x Vdd
27 P1-0 Gnd tied
28 .. Gnd tied
29x .. floating
30x .. floating
31x .. floating
32x .. floating
33x .. floating
34x .. floating
35x P2-4 floating
36x .. floating
37x .. floating
38x P2-7 floating
39x T1
40x Vcc