 |
Search Sci.Electronics.Basics |
|
|
|
|
|
|
 |
|
|
Sci.Electronics.Basics -> microcontroller ROM copy trouble ?
There are 60 messages in this thread.
You are currently looking at messages 20 to 40.
|
Author: robbDate: 02:53 29-12-07
|
|
<gqrxzy8974@ftml.net> wrote in message
news:e16006dc-aebf-4d57-8a46-8a1e9409e066@e23g2000prf.googlegroups.com...
> > well oddly on this board the (pin 1) is hardwired to (pin 27)
> > for the original chip that is ( NC to Addr 14) on the
**new**
> > 27c256 that would be (Vpp to Addr 14)
>
> That doesn't sound odd as pin 1 would be A15 on the next
> size up ROM.
>
i think i may not be clear ?
i am saying pin 1 and pin 27 of the memory chip are connected on
the controller board so that would cause special consideration if
one wanted to use a 27c512 ?
>
> > so i **tried** insert new 27C256 into socket with (pin 1) not
> > making contact(bend pin and slide to outside of socket) then
> > attach micro-jumper hooks from (pin 1) to Vcc
> > and this did not have any effect ??
>
> OK, so that's not the problem.
>
> > so now i am wondeing if i am even reading the original Chip
> > correctly it is ***NOT*** directly supported /mentioned in my
ROM
> > reader but it has similar equivalents by my judgement but
the
> > data does not look like it is thr 8051 processor instructions
as
> > i would expect.
>
> Have you looked at a hex dump of the ROM? Perhaps
> it didn't really enabel the ROM when reading it and you
> "read" all FF or something like it from the original ROM and
> it programmed your new EPROM with that.
>
close , it is a series of sections of 64 duplicate bytes
followed by another section of 64 duplicate bytes..... all the
waty to the end
each section of byte values is different and i get the exact
same series for each successive chip reading attempts.
unless i choose a different chip size like 27c128 then the series
of byte duplicates changes. where the first set maybe 7A in place
of the 02
here is a clip from begining of my read
:020000040000FA
:1000000002020202020202020202020202020202D0
:1000100002020202020202020202020202020202C0
:1000200002020202020202020202020202020202B0
:1000300002020202020202020202020202020202A0
:100040000202020202020202020202020202020290
:100050000202020202020202020202020202020280
:100060000202020202020202020202020202020270
:100070000202020202020202020202020202020260
:10008000D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9E0
:10009000D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9D0
:1000A000D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9C0
:1000B000D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9B0
:1000C000D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9A0
:1000D000D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9D990
:1000E000D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9D980
:1000F000D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9D970
:10010000E6E6E6E6E6E6E6E6E6E6E6E6E6E6E6E68F
:10011000E6E6E6E6E6E6E6E6E6E6E6E6E6E6E6E67F
:10012000E6E6E6E6E6E6E6E6E6E6E6E6E6E6E6E66F
:10013000E6E6E6E6E6E6E6E6E6E6E6E6E6E6E6E65F
:10014000E6E6E6E6E6E6E6E6E6E6E6E6E6E6E6E64F
:10015000E6E6E6E6E6E6E6E6E6E6E6E6E6E6E6E63F
:10016000E6E6E6E6E6E6E6E6E6E6E6E6E6E6E6E62F
:10017000E6E6E6E6E6E6E6E6E6E6E6E6E6E6E6E61F
:1001800039393939393939393939393939393939DF
:1001900039393939393939393939393939393939CF
:1001A00039393939393939393939393939393939BF
:1001B00039393939393939393939393939393939AF
:1001C000393939393939393939393939393939399F
:1001D000393939393939393939393939393939398F
:1001E000393939393939393939393939393939397F
:1001F000393939393939393939393939393939396F
:1002000013131313131313131313131313131313BE
:1002100013131313131313131313131313131313AE
:10022000131313131313131313131313131313139E
:10023000131313131313131313131313131313138E
:10024000131313131313131313131313131313137E
:10025000131313131313131313131313131313136E
:10026000131313131313131313131313131313135E
:10027000131313131313131313131313131313134E
:100280001E1E1E1E1E1E1E1E1E1E1E1E1E1E1E1E8E
.... till the end
>
> Mask ROMs can have additional chip selects (if pins are
> available) and these can be (mask programmed) to select
> on high or low. There may or may not be an OE (possibly
> just the chip select(s)).
>
I mapped the pins on the board so as to be reasonably certain
that the ROM chip was compatible with the 27cXXX series of chips
all the pin/address/data lines seem to be consistent with the
27cXXX series pin out. the data and address lines match to the
MCU adressing pins according to 27cXXX datasheet even the funny 8
through 11 pin jumble.
(pin 22) ROM goes to (pin 29) 8051 (PSEN- prog store enable)
(pin 20) ROM goes to (pin 30)8051 (ALE-Addr Latch Enable)
on the PCB the 8 data lines are all connected with the first 8
Address lines
so D0 is connected to A0 and (D1 to A1) and these shared
connection s all go back to MCU
> It's a 28 pin chip and has to have gnd, Vcc, 8 data,
> 15 address so that leaves 3 pins. The eprom
> has CE, OE, and Vpp; the ROM might have
> 3 more chip selects or some number of chip selects
> plus OE?
>
> It sounds solvable...
>
thanks for the help,
robb
|
|
|
|
Author: TT_ManDate: 05:31 29-12-07
|
|
"mpm" <mpmillard@aol.com> wrote in message
news:08ba70e9-b057-4d39-9962-7f2aafba453f@e25g2000prg.googlegroups.com...
On Dec 27, 2:28?pm, "robb" <s...@where.on.net> wrote:
> thanks for any help i ?am stuck again,
> robb
Honestly, I just skimmed the replies, and don't have the time to get
into great detail about what might be wrong....
However, if I recall correctly, parallel EPROMs used to have
"Signature Bytes".
In the old days, that's how a programmer "knew" what programming
voltage / algorithm to use....
Could be the 8031 code is reading this, before allowing normal
operation. (Wild ass guess, btw)
Or, perhaps more likely, your programmer isn't really programming the
new EPROM and its just lying to you.??
Hope you figure it out. Good luck.
-mpm
Utter rubbish.....the 8031 isn't reading sig bytes...
Your programmer is not reading the eprom correctly.
|
|
|
|
Author: Ian MalcolmDate: 05:58 29-12-07
|
|
robb wrote:
> <gqrxzy8974@ftml.net> wrote in message
> news:e16006dc-aebf-4d57-8a46-8a1e9409e066@e23g2000prf.googlegroups.com...
>
>>>well oddly on this board the (pin 1) is hardwired to (pin 27)
>>>for the original chip that is ( NC to Addr 14) on the
>
> **new**
>
>>>27c256 that would be (Vpp to Addr 14)
>>
>>That doesn't sound odd as pin 1 would be A15 on the next
>>size up ROM.
>>
>
> i think i may not be clear ?
> i am saying pin 1 and pin 27 of the memory chip are connected on
> the controller board so that would cause special consideration if
> one wanted to use a 27c512 ?
>
>
>>>so i **tried** insert new 27C256 into socket with (pin 1) not
>>>making contact(bend pin and slide to outside of socket) then
>>>attach micro-jumper hooks from (pin 1) to Vcc
>>>and this did not have any effect ??
>>
>>OK, so that's not the problem.
>>
>>
>>>so now i am wondeing if i am even reading the original Chip
>>>correctly it is ***NOT*** directly supported /mentioned in my
>
> ROM
>
>>>reader but it has similar equivalents by my judgement but
>
> the
>
>>>data does not look like it is thr 8051 processor instructions
>
> as
>
>>>i would expect.
>>
>>Have you looked at a hex dump of the ROM? Perhaps
>>it didn't really enabel the ROM when reading it and you
>>"read" all FF or something like it from the original ROM and
>>it programmed your new EPROM with that.
>>
>
>
> close , it is a series of sections of 64 duplicate bytes
> followed by another section of 64 duplicate bytes..... all the
> waty to the end
>
> each section of byte values is different and i get the exact
> same series for each successive chip reading attempts.
>
> unless i choose a different chip size like 27c128 then the series
> of byte duplicates changes. where the first set maybe 7A in place
> of the 02
>
> here is a clip from begining of my read
>
> :020000040000FA
> :1000000002020202020202020202020202020202D0
> :1000100002020202020202020202020202020202C0
> :1000200002020202020202020202020202020202B0
> :1000300002020202020202020202020202020202A0
> :100040000202020202020202020202020202020290
> :100050000202020202020202020202020202020280
> :100060000202020202020202020202020202020270
> :100070000202020202020202020202020202020260
> :10008000D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9E0
> :10009000D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9D0
> :1000A000D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9C0
> :1000B000D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9B0
> :1000C000D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9A0
> :1000D000D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9D990
> :1000E000D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9D980
> :1000F000D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9D970
> :10010000E6E6E6E6E6E6E6E6E6E6E6E6E6E6E6E68F
> :10011000E6E6E6E6E6E6E6E6E6E6E6E6E6E6E6E67F
> :10012000E6E6E6E6E6E6E6E6E6E6E6E6E6E6E6E66F
> :10013000E6E6E6E6E6E6E6E6E6E6E6E6E6E6E6E65F
> :10014000E6E6E6E6E6E6E6E6E6E6E6E6E6E6E6E64F
> :10015000E6E6E6E6E6E6E6E6E6E6E6E6E6E6E6E63F
> :10016000E6E6E6E6E6E6E6E6E6E6E6E6E6E6E6E62F
> :10017000E6E6E6E6E6E6E6E6E6E6E6E6E6E6E6E61F
> :1001800039393939393939393939393939393939DF
> :1001900039393939393939393939393939393939CF
> :1001A00039393939393939393939393939393939BF
> :1001B00039393939393939393939393939393939AF
> :1001C000393939393939393939393939393939399F
> :1001D000393939393939393939393939393939398F
> :1001E000393939393939393939393939393939397F
> :1001F000393939393939393939393939393939396F
> :1002000013131313131313131313131313131313BE
> :1002100013131313131313131313131313131313AE
> :10022000131313131313131313131313131313139E
> :10023000131313131313131313131313131313138E
> :10024000131313131313131313131313131313137E
> :10025000131313131313131313131313131313136E
> :10026000131313131313131313131313131313135E
> :10027000131313131313131313131313131313134E
> :100280001E1E1E1E1E1E1E1E1E1E1E1E1E1E1E1E8E
> .... till the end
>
>
>
>>Mask ROMs can have additional chip selects (if pins are
>>available) and these can be (mask programmed) to select
>>on high or low. There may or may not be an OE (possibly
>>just the chip select(s)).
>>
>
>
> I mapped the pins on the board so as to be reasonably certain
> that the ROM chip was compatible with the 27cXXX series of chips
>
> all the pin/address/data lines seem to be consistent with the
> 27cXXX series pin out. the data and address lines match to the
> MCU adressing pins according to 27cXXX datasheet even the funny 8
> through 11 pin jumble.
>
> (pin 22) ROM goes to (pin 29) 8051 (PSEN- prog store enable)
> (pin 20) ROM goes to (pin 30)8051 (ALE-Addr Latch Enable)
>
> on the PCB the 8 data lines are all connected with the first 8
> Address lines
> so D0 is connected to A0 and (D1 to A1) and these shared
> connection s all go back to MCU
>
>
>
>>It's a 28 pin chip and has to have gnd, Vcc, 8 data,
>>15 address so that leaves 3 pins. The eprom
>>has CE, OE, and Vpp; the ROM might have
>>3 more chip selects or some number of chip selects
>>plus OE?
>>
>>It sounds solvable...
>>
>
>
> thanks for the help,
> robb
>
>
It would seem your original rom has an internal address latch.
There is *some* evidence that 23256 roms with this feature may have been
used by HP, but I have had no success finding a NEC data sheet for your
rom. This would explain why the eprom reader reads the same value 64
times and also why there is no 8 bit latch chip between the multiplexed
d0-7/A0-7 MCU bus and the rom's A0-7 address inputs. Try a different
algorithm for reading the rom on the programmer. When you've go the
correct contents that dissasemble to something reasonable, you'll need
to put a little board together to insert a latch between the combined
bus and the adddress pins, then program a 27c256 and try it.
HTH
--
Ian Malcolm. London, ENGLAND. (NEWSGROUP REPLY PREFERRED)
ianm[at]the[dash]malcolms[dot]freeserve[dot]co[dot]uk
[at]=@, [dash]=- & [dot]=. *Warning* HTML & >32K emails --> NUL:
'Stingo' Albacore #1554 - 15' Early 60's, Uffa Fox designed,
All varnished hot moulded wooden racing dinghy.
|
|
|
|
Author: EeyoreDate: 06:32 29-12-07
|
|
robb wrote:
> here is a clip from begining of my read
>
> :020000040000FA
> :1000000002020202020202020202020202020202D0
> :1000100002020202020202020202020202020202C0
> :1000200002020202020202020202020202020202B0
> :1000300002020202020202020202020202020202A0
> :100040000202020202020202020202020202020290
> :100050000202020202020202020202020202020280
> :100060000202020202020202020202020202020270
> :100070000202020202020202020202020202020260
> :10008000D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9E0
> :10009000D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9D0
> :1000A000D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9C0
> :1000B000D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9B0
> :1000C000D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9A0
> :1000D000D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9D990
> :1000E000D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9D980
> :1000F000D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9D970
> :10010000E6E6E6E6E6E6E6E6E6E6E6E6E6E6E6E68F
> :10011000E6E6E6E6E6E6E6E6E6E6E6E6E6E6E6E67F
> :10012000E6E6E6E6E6E6E6E6E6E6E6E6E6E6E6E66F
> :10013000E6E6E6E6E6E6E6E6E6E6E6E6E6E6E6E65F
> :10014000E6E6E6E6E6E6E6E6E6E6E6E6E6E6E6E64F
> :10015000E6E6E6E6E6E6E6E6E6E6E6E6E6E6E6E63F
> :10016000E6E6E6E6E6E6E6E6E6E6E6E6E6E6E6E62F
> :10017000E6E6E6E6E6E6E6E6E6E6E6E6E6E6E6E61F
> :1001800039393939393939393939393939393939DF
> :1001900039393939393939393939393939393939CF
> :1001A00039393939393939393939393939393939BF
> :1001B00039393939393939393939393939393939AF
> :1001C000393939393939393939393939393939399F
> :1001D000393939393939393939393939393939398F
> :1001E000393939393939393939393939393939397F
> :1001F000393939393939393939393939393939396F
> :1002000013131313131313131313131313131313BE
> :1002100013131313131313131313131313131313AE
> :10022000131313131313131313131313131313139E
> :10023000131313131313131313131313131313138E
> :10024000131313131313131313131313131313137E
> :10025000131313131313131313131313131313136E
> :10026000131313131313131313131313131313135E
> :10027000131313131313131313131313131313134E
> :100280001E1E1E1E1E1E1E1E1E1E1E1E1E1E1E1E8E
> .... till the end
Looks like gibberish to me.
What happens if you try reading it as a 27C512 ? Just an idea.
Graham
|
|
|
|
Author: mpmDate: 11:19 29-12-07
|
|
On Dec 28, 12:43=EF=BF=BDpm, "robb" <s...@where.on.net> wrote:
> so now i am wondeing if i am even reading the original Chip
> correctly it is ***NOT*** directly supported /mentioned in my ROM
> reader but it has similar equivalents by my judgement =EF=BF=BDbut the
> data does not look like it is thr 8051 processor instructions as
> i would expect.
The above seems to be the problem.
Your programmer is not reading the original ROM (23xxx) chip
correctly.
However, it "is" reading something.
Later you burn another chip, and this chip correctly burns what was
read previously.
The only problem is, the original read was not right, so it matters
not if the two compare!!
I still contend this is a read problem on the original ROM, likely
related to the signature byte.
To my knowledge, you are unlikely to blow up the original ROM using
read voltages.
As long as you don't try to program it.
So, if you feel its worth the attempt, you could try other 27256
settings and see if you can get something that looks reasonably close
to 8031 opcodes. (?)
Another posted commented that your 23xxx might have internal address
latches.
Honestly, I've never heard of that. I doubt they exist, but I could
be wrong.
I am assuming the 23xxx is a factory-masked ROM (i.e., no eprom quartz
window).
If that's the case, very often the 23xxx programming info is on the
same datasheet as the 27xxx of the same manufacturer and model
series. It might be worth googeling...
And of course, if there are pinout differences between the masked-rom
and eprom versions, your programmer would need to know about these...
and hence we're back to the signature bytes. Good luck.
-mpm
|
|
|
|
Author: mpmDate: 11:21 29-12-07
|
|
On Dec 29, 5:31=EF=BF=BDam, "TT_Man" <Some...@ntlworld.com> wrote:
> "mpm" <mpmill...@aol.com> wrote in message
>
> news:08ba70e9-b057-4d39-9962-7f2aafba453f@e25g2000prg.googlegroups.com...
> On Dec 27, 2:28?pm, "robb" <s...@where.on.net> wrote:
>
> > thanks for any help i ?am stuck again,
> > robb
>
> Honestly, I just skimmed the replies, and don't have the time to get
> into great detail about what might be wrong....
>
> However, if I recall correctly, parallel EPROMs used to have
> "Signature Bytes".
> In the old days, that's how a programmer "knew" what programming
> voltage / algorithm to use....
>
> Could be the 8031 code is reading this, before allowing normal
> operation. =EF=BF=BD(Wild ass guess, btw)
> Or, perhaps more likely, your programmer isn't really programming the
> new EPROM and its just lying to you.??
>
> Hope you figure it out. =EF=BF=BDGood luck.
> -mpm
>
> Utter rubbish.....the 8031 isn't reading sig bytes...
> Your programmer is not reading the eprom correctly.
I agree, now that I have read the replies more thoroughly, esp, post
#3, it would appear that your programmer is not reading the original
masked ROM part correctly.
|
|
|
|
Author: TT_ManDate: 12:15 29-12-07
|
|
> Hope you figure it out. ?Good luck.
> -mpm
>
> Utter rubbish.....the 8031 isn't reading sig bytes...
> Your programmer is not reading the eprom correctly.
I agree, now that I have read the replies more thoroughly, esp, post
#3, it would appear that your programmer is not reading the original
masked ROM part correctly.
This is what I have found out about UPD23C256E.....
The OE signal is mask option selectable and can be active hi, low or don't
care.
Put the chip in your reader, but bend out the OE leg ( pin 22). Connect it
via a 1K resistor to Vcc and then read as 'any' 27256 EPROM.
Look at the data and see if it looks 'real'.
If not, leave pin 22 'not connected 'and read again......
I don't think it's worth trying to connect OE to GND as that is the default
for all generic 27356 devices.
|
|
|
|
Author: EeyoreDate: 12:38 29-12-07
|
|
TT_Man wrote:
> > Hope you figure it out. ?Good luck.
> > -mpm
> >
> > Utter rubbish.....the 8031 isn't reading sig bytes...
> > Your programmer is not reading the eprom correctly.
>
> I agree, now that I have read the replies more thoroughly, esp, post
> #3, it would appear that your programmer is not reading the original
> masked ROM part correctly.
>
> This is what I have found out about UPD23C256E.....
> The OE signal is mask option selectable and can be active hi, low or don't
> care.
>
> Put the chip in your reader, but bend out the OE leg ( pin 22). Connect it
> via a 1K resistor to Vcc and then read as 'any' 27256 EPROM.
> Look at the data and see if it looks 'real'.
> If not, leave pin 22 'not connected 'and read again......
> I don't think it's worth trying to connect OE to GND as that is the default
> for all generic 27356 devices.
Not to mention that if /OE is tied in some unusual way on his board, it also
won't work with standard Eproms.
It might be an idea to see if pin22 of the ROM socker is tied low.
Graham
|
|
|
|
Author: robbDate: 13:08 29-12-07
|
|
"mpm" <mpmillard@aol.com> wrote in message
news:7744ce75-1258-4abb-8af2-6af4e203cd02@x69g2000hsx.googlegroups.com...
On Dec 28, 12:43�pm, "robb" <s...@where.on.net> wrote:
> >
> > so now i am wondeing if i am even reading the original Chip
> > correctly it is ***NOT*** directly supported /mentioned in my
ROM
> > reader but it has similar equivalents by my judgement �but
the
> > data does not look like it is thr 8051 processor instructions
as
> > i would expect.
>
> The above seems to be the problem.
> Your programmer is not reading the original ROM (23xxx) chip
> correctly.
> However, it "is" reading something.
> Later you burn another chip, and this chip correctly burns what
was
> read previously.
> The only problem is, the original read was not right, so it
matters
> not if the two compare!!
>
> I still contend this is a read problem on the original ROM,
likely
> related to the signature byte.
> To my knowledge, you are unlikely to blow up the original ROM
using
> read voltages.
> As long as you don't try to program it.
> So, if you feel its worth the attempt, you could try other
27256
> settings and see if you can get something that looks reasonably
close
> to 8031 opcodes. (?)
>
Thanks for all the help and info mpm,
i am really stuck and appreciate your's and everyones efforts to
get me going.
that is exactly what i have been trying since the latest round of
**bad ROM read** diagnosis.
I have been selecting a variety of different chip makers versions
of 27cXXX where XXX is {64,128,256,512}... additionally i have
been choosing different sizes of reads to see if i get anything
that looks like some 8051/8031 op codes. so 0xf to 0x7fff bytes
and in between
the only difference is that sometimes the sequence of bytes i get
have a different values for the different sized chips
so.... that means a (27c128) read will get me a different
sequence of repeated chars than say a (27c256) read
>
> Another posted commented that your 23xxx might have internal
address
> latches.
>
well that advice was based on the fact that i traced the pins
connection on the controller circuit board to try and decipher
what this chip might actaulally be and i found that the
Address lines 0-7 were tied to the Data lines 0-7 and then they
made ther way to the appropriate 8051 lines so being multiplexed
someone though there must be latching operation...
the only 23xxx datasheet i found (toshiba TMM23256P) says ...
that it uses a Address Latch on the falling edge of (CE) and
latches all inputs except for (OE) to provide data bus
compatibility and has a reference to 3-State outputs or Wired
OR capability ????? what that means ????
My pin trace is.....
Where Rom is the same ROM there is only 1 ROM
this views best in fixed width eg. courier
Rom(pin) Rom(pin) 8051 (pin)
------------------------------------------
A0 (p10) D0 (p11) P0.0 (p39)
A1 (p9) D1 (p12) P0.1 (p38)
A2 (p8) D2 (p13) P0.2 (p37)
......
A8 (p25) --- P2.0 (p21)
A9 (p24) --- P2.1 (p22)
.....
A14 (p27) A15 (p1) P2.6 (p27)
.....
OE (p22) --- PSEN (p29)
CE (p20) --- ALE (p30)
> Honestly, I've never heard of that. I doubt they exist, but
I could
> be wrong.
> I am assuming the 23xxx is a factory-masked ROM (i.e., no eprom
quartz
> window).
> If that's the case, very often the 23xxx programming info is on
the
> same datasheet as the 27xxx of the same manufacturer and model
> series. It might be worth googeling...
>
> And of course, if there are pinout differences between the
masked-rom
> and eprom versions, your programmer would need to know about
these...
> and hence we're back to the signature bytes. Good luck.
>
thanks again MPM,
i really do appreciate the help. hopefully i will solve or find
more useful info that someone can give me an indication of what i
need to do to solve this problem
i am thinikng i will need to use some 8051 development board and
write my own application to grab data and put somewhere to upload
or print on serial port or something
sound feasible,...
Thanks again for help,
robb
|
|
|
|
Author: robbDate: 14:23 29-12-07
|
|
"TT_Man" <Someone@ntlworld.com> wrote in message
news:rgvdj.17507$745.840@newsfe1-win.ntli.net...
>
> > Hope you figure it out. ?Good luck.
> > -mpm
> >
> > Utter rubbish.....the 8031 isn't reading sig bytes...
> > Your programmer is not reading the eprom correctly.
>
> I agree, now that I have read the replies more thoroughly, esp,
post
> #3, it would appear that your programmer is not reading the
original
> masked ROM part correctly.
>
> This is what I have found out about UPD23C256E.....
> The OE signal is mask option selectable and can be active hi,
low or don't
> care.
>
> Put the chip in your reader, but bend out the OE leg ( pin
22). Connect it
> via a 1K resistor to Vcc and then read as 'any' 27256 EPROM.
> Look at the data and see if it looks 'real'.
> If not, leave pin 22 'not connected 'and read again......
> I don't think it's worth trying to connect OE to GND as that is
the default
> for all generic 27356 devices.
>
thanks TT_MAN,
ok, interesting experiment,
when i tie the p22 (oe) high then i read all 0xFF all the way
floating gives similar as when connected
reading a troshiba 23256 mask rom datasheet it showed that the
latch occurs at trailing edge of (CE) so (CE) falls about halfway
through the adress valid ... but most timing diagrams for 27cXXX
chips show the (CE) falling at or just before the address valid
section
so i do not know how that timing could affect what i am doing. i
suppose i need to find out what the ROM programmer is doing.
programmer is an "Easypro90" if anyone has any knowledge of
these?
thanks for helping,
robb
|
|
|
|
Author: EeyoreDate: 14:30 29-12-07
|
|
robb wrote:
> when i tie the p22 (oe) high then i read all 0xFF all the way
> floating gives similar as when connected
Now tie it low.
AND look at how it's connected on the equipment pcb.
Graham
|
|
|
|
Author: donaldDate: 14:32 29-12-07
|
|
Lets start with a few basics.
Plesae post from your reader the first 16 bytes of the ROM file.
If this does not look right, then everything else will be off.
If the reader can not read it, it won't be able to write anything that
makes sense.
You could always run the exorcised binary file thru a dis-assembler,
re-assemble it, program your EEPROM and see if that runs.
donald
|
|
|
|
Author: robbDate: 14:39 29-12-07
|
|
"Eeyore" <rabbitsfriendsandrelations@hotmail.com> wrote in
message news:47768628.E505059B@hotmail.com...
>
>
> TT_Man wrote:
>
> > I agree, now that I have read the replies more thoroughly,
esp, post
> > #3, it would appear that your programmer is not reading the
original
> > masked ROM part correctly.
> >
> > This is what I have found out about UPD23C256E.....
> > The OE signal is mask option selectable and can be active hi,
low or don't
> > care.
> >
> > Put the chip in your reader, but bend out the OE leg ( pin
22). Connect it
> > via a 1K resistor to Vcc and then read as 'any' 27256 EPROM.
> > Look at the data and see if it looks 'real'.
> > If not, leave pin 22 'not connected 'and read again......
> > I don't think it's worth trying to connect OE to GND as that
is the default
> > for all generic 27356 devices.
>
> Not to mention that if /OE is tied in some unusual way on his
board, it also
> won't work with standard Eproms.
>
> It might be an idea to see if pin22 of the ROM socker is tied
low.
>
> Graham
>
Thanks for the help,
I tried out the ideas you suggested.
that is .... select different ROM types and i also tried with
differing read lengths for 0xf to 0x7fff or whatever the max size
is and all the same results
except that different 27cXXX types gives me different sequence of
repeated bytes
i tried the OE pin out and jumpering pins and such
i think maybe my programmer is just crap it is an "Easypro90" and
it supports lots of chips but apparently not the one i need
i highlighted the pinout and traces of the ROM chip in another
post i will put it here ....
My pin trace is.....
Where Rom is the same ROM there is only 1 ROM
this views best in fixed width eg. courier
Rom(pin) Rom(pin) 8051 (pin)
------------------------------------------
A0 (p10) D0 (p11) P0.0 (p39)
A1 (p9) D1 (p12) P0.1 (p38)
A2 (p8) D2 (p13) P0.2 (p37)
......
A8 (p25) --- P2.0 (p21)
A9 (p24) --- P2.1 (p22)
.....
A14 (p27) A15 (p1) P2.6 (p27)
.....
OE (p22) --- PSEN (p29)
CE (p20) --- ALE (p30)
one thing i have come across that may help is that the oly mask
ROM datasheet i have found (Toshiba TMM23256P) says that the chip
has Adress latch on falling edge of (CE) and the timing diagrm
shows the falling CE edge occurs in middle of address valid
section, on most 27cXXX chips the timing diagram shows the
falling edge of CE occurs just at or before the valid address
section but i do not know if that should make a diference ??
Thanks for all the help Graham, as i relly need it to get out of
this jam.
do you think it would be difficult to program a 8051 development
board to read this data and say dump it somewhere to pick it up .
seems like it should be easy enough ??? i have a PJRC Rev 4
board http://www.pjrc.com/
that i got with the ROM programmer pretty cheap
i do not know if my Programmer will alloew you to write a custom
algorithm but i ahve not found any info on the easypro site to
that regard.
thanks again,
robb
|
|
|
|
Author: robbDate: 14:48 29-12-07
|
|
"donald" <Donald@dontdoithere.com> wrote in message
news:Wsedncn0c70wPevanZ2dnUVZ_sqinZ2d@comcast.com...
> Lets start with a few basics.
>
> Plesae post from your reader the first 16 bytes of the ROM
file.
>
> If this does not look right, then everything else will be off.
>
> If the reader can not read it, it won't be able to write
anything that
> makes sense.
>
> You could always run the exorcised binary file thru a
dis-assembler,
> re-assemble it, program your EEPROM and see if that runs.
>
> donald
Hello donald thanks for the help,
i agree if you getting crap you write crap,
i though i had allready tested the ROM reads previously and had
success but when i went to recheck i found that the other
microcontroller board was using a 8051 with internal programand
not even uing the ROM
so now i realise that it is reading the ROM that is my problem.
so now how to get programmer to read these ROMS ??
here are first lines from "Easypro90B" programmer read
:020000040000FA
:1000000002020202020202020202020202020202D0
:1000100002020202020202020202020202020202C0
any experience dumping memorywith a 8051 development board ?
i have PJRC Rev 4 board http://www.pjrc.com/
easier than getting the EasyPRO90B to do it ???
thanks again for the help,
robb
|
|
|
|
Author: donaldDate: 15:42 29-12-07
|
|
robb wrote:
> "donald" <Donald@dontdoithere.com> wrote in message
> news:Wsedncn0c70wPevanZ2dnUVZ_sqinZ2d@comcast.com...
>
>>Lets start with a few basics.
>>
>>Plesae post from your reader the first 16 bytes of the ROM
>
> file.
>
>>If this does not look right, then everything else will be off.
>>
>>If the reader can not read it, it won't be able to write
>
> anything that
>
>>makes sense.
>>
>>You could always run the exorcised binary file thru a
>
> dis-assembler,
>
>>re-assemble it, program your EEPROM and see if that runs.
>>
>>donald
>
>
> Hello donald thanks for the help,
>
> i agree if you getting crap you write crap,
>
> i though i had allready tested the ROM reads previously and had
> success but when i went to recheck i found that the other
> microcontroller board was using a 8051 with internal programand
> not even uing the ROM
>
> so now i realise that it is reading the ROM that is my problem.
>
> so now how to get programmer to read these ROMS ??
>
> here are first lines from "Easypro90B" programmer read
>
> :020000040000FA
> :10 0000 00 02 0202 02020202020202020202020202D0
> :1000100002020202020202020202020202020202C0
>
> any experience dumping memorywith a 8051 development board ?
> i have PJRC Rev 4 board http://www.pjrc.com/
>
> easier than getting the EasyPRO90B to do it ???
>
> thanks again for the help,
> robb
>
>
Ok, here is your first problem.
At address 0x000 should be a jump to a start address.
02 is a long jmp op-code a nd the target address looks like 0x0202.
http://www.win.tue.nl/~aeb/comp/8051/set8051.html
But then all the interrupt vectors are long jumping to the same address.
This is a problem.
If you can share the entire hex file, maybe someone here be able to help
you read it.
Another idea.
Maybe the address lines are mixed up, so a strait copy would be worng.
good luck.
donald
|
|
|
|
Author: Henry KieferDate: 16:10 29-12-07
|
|
donald schrieb:
> Ok, here is your first problem.
>
> At address 0x000 should be a jump to a start address.
>
> 02 is a long jmp op-code a nd the target address looks like 0x0202.
>
> http://www.win.tue.nl/~aeb/comp/8051/set8051.html
>
> But then all the interrupt vectors are long jumping to the same address.
>
> This is a problem.
>
> If you can share the entire hex file, maybe someone here be able to help
> you read it.
>
> Another idea.
>
> Maybe the address lines are mixed up, so a strait copy would be worng.
>
> good luck.
>
Hint if you read garbage:
Sometimes there is added simple encryption by mixing address and/or data
lines between controller and memory. You should check that!
This encryption type does allow copying the ROM but makes it hard to
disassemble it.
- Henry
--
www.ehydra.dyndns.info
|
|
|
|
Author: donaldDate: 16:27 29-12-07
|
|
Henry Kiefer wrote:
> donald schrieb:
>
>> Ok, here is your first problem.
>>
>> At address 0x000 should be a jump to a start address.
>>
>> 02 is a long jmp op-code a nd the target address looks like 0x0202.
>>
>> http://www.win.tue.nl/~aeb/comp/8051/set8051.html
>>
>> But then all the interrupt vectors are long jumping to the same address.
>>
>> This is a problem.
>>
>> If you can share the entire hex file, maybe someone here be able to
>> help you read it.
>>
>> Another idea.
>>
>> Maybe the address lines are mixed up, so a strait copy would be worng.
>>
>> good luck.
>>
>
> Hint if you read garbage:
> Sometimes there is added simple encryption by mixing address and/or data
> lines between controller and memory. You should check that!
>
> This encryption type does allow copying the ROM but makes it hard to
> disassemble it.
>
>
> - Henry
>
>
>
You are correct, the bytes and bits should be in the same location after
the copy, even if the address/data lines are mixed up.
Encryption would imply that the data/address path is moved around.
So, OP, is there any other chips in the data/address path ??
donald
|
|
|
|
Author: Henry KieferDate: 16:59 29-12-07
|
|
donald schrieb:
> Henry Kiefer wrote:
>
>> donald schrieb:
>>
>>> Ok, here is your first problem.
>>>
>>> At address 0x000 should be a jump to a start address.
>>>
>>> 02 is a long jmp op-code a nd the target address looks like 0x0202.
>>>
>>> http://www.win.tue.nl/~aeb/comp/8051/set8051.html
>>>
>>> But then all the interrupt vectors are long jumping to the same address.
>>>
>>> This is a problem.
>>>
>>> If you can share the entire hex file, maybe someone here be able to
>>> help you read it.
>>>
>>> Another idea.
>>>
>>> Maybe the address lines are mixed up, so a strait copy would be worng.
>>>
>>> good luck.
>>>
>>
>> Hint if you read garbage:
>> Sometimes there is added simple encryption by mixing address and/or
>> data lines between controller and memory. You should check that!
>>
>> This encryption type does allow copying the ROM but makes it hard to
>> disassemble it.
>>
>>
>> - Henry
>>
>>
>>
> You are correct, the bytes and bits should be in the same location after
> the copy, even if the address/data lines are mixed up.
>
> Encryption would imply that the data/address path is moved around.
>
> So, OP, is there any other chips in the data/address path ??
Think simple, for example: Exchange A14 with A15 and D4 with D2 between
controller and memory. Gives garbage in Reader, but controller works (if
the manufacturer wrote a simple exchanger prog before programming the ROM).
- Henry
--
www.ehydra.dyndns.info
|
|
|
|
Author: donaldDate: 17:29 29-12-07
|
|
Henry Kiefer wrote:
> donald schrieb:
>
>> Henry Kiefer wrote:
>>
>>> donald schrieb:
>>>
>>>> Ok, here is your first problem.
>>>>
>>>> At address 0x000 should be a jump to a start address.
>>>>
>>>> 02 is a long jmp op-code a nd the target address looks like 0x0202.
>>>>
>>>> http://www.win.tue.nl/~aeb/comp/8051/set8051.html
>>>>
>>>> But then all the interrupt vectors are long jumping to the same
>>>> address.
>>>>
>>>> This is a problem.
>>>>
>>>> If you can share the entire hex file, maybe someone here be able to
>>>> help you read it.
>>>>
>>>> Another idea.
>>>>
>>>> Maybe the address lines are mixed up, so a strait copy would be worng.
>>>>
>>>> good luck.
>>>>
>>>
>>> Hint if you read garbage:
>>> Sometimes there is added simple encryption by mixing address and/or
>>> data lines between controller and memory. You should check that!
>>>
>>> This encryption type does allow copying the ROM but makes it hard to
>>> disassemble it.
>>>
>>>
>>> - Henry
>>>
>>>
>>>
>> You are correct, the bytes and bits should be in the same location
>> after the copy, even if the address/data lines are mixed up.
>>
>> Encryption would imply that the data/address path is moved around.
>>
>> So, OP, is there any other chips in the data/address path ??
>
>
> Think simple, for example: Exchange A14 with A15 and D4 with D2 between
> controller and memory. Gives garbage in Reader, but controller works (if
> the manufacturer wrote a simple exchanger prog before programming the ROM).
>
>
> - Henry
>
>
The sample lines the OP showed us looks like the pages may be shifted
around.
Looking at the vectors kind of indicated that.
Don't you just love trouble shooting in the dark ?
donald
|
|
|
|
Author: Henry KieferDate: 17:38 29-12-07
|
|
donald schrieb:
>>> You are correct, the bytes and bits should be in the same location
>>> after the copy, even if the address/data lines are mixed up.
>>>
>>> Encryption would imply that the data/address path is moved around.
>>>
>>> So, OP, is there any other chips in the data/address path ??
>>
>>
>> Think simple, for example: Exchange A14 with A15 and D4 with D2
>> between controller and memory. Gives garbage in Reader, but controller
>> works (if the manufacturer wrote a simple exchanger prog before
>> programming the ROM).
>>
>>
>> - Henry
>>
>>
> The sample lines the OP showed us looks like the pages may be shifted
> around.
>
That was the trigger for me.
> Looking at the vectors kind of indicated that.
>
I don't spent time to read all posting, sorry.
> Don't you just love trouble shooting in the dark ?
>
That is my job to shot. I like it since 25 years.
Greetings -
Henry
--
www.ehydra.dyndns.info
|
|
|
|
|
|
|
|
|
Contact | Electronic Portal
|
|
|
