microcontroller ROM copy trouble ?

post

original

low or don't

the default

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

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

file.

anything that

dis-assembler,

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

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.

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

donald schrieb:

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

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

donald schrieb:

That was the trigger for me.

I don't spent time to read all posting, sorry.

That is my job to shot. I like it since 25 years.

Greetings - Henry

Active HIGH versus Active LOW on CS and OE pins? Maybe the EPROM programmer is able to compensate for that and "do the right thing", but your target circuit can't? Been through that recently with some EPROM/ROMs and it is a pain.

Get data sheets for both chips and look closely.

"Nearly" tell that to Apple and Sinclair.

Apple II Europlus O/S ROMS wouldn't read on my EPROM programmer without some fiddling about to come up with CS (Chip select) HIGH and VPP/OE LOW. (Normal would be BOTH low)

Sinclair QL OS ROMS are odder still: OE required to be HIGH, CS is active LOW on one chip, active HIGH on another. The CS lines are tied together in the computer, so it makes sense. However, for an EPROM programmer, it's backwards.

Also run it through an ASCII dump, look for any copyright strings that make sense.

Where are you located in the UK?

and/or data

hard to

location after

around.

Hello Don and Kiefer, thanks for taking time and trying to help.

I wondered about the encryption myself considering all the trouble reading a simple ROM chip to burn another,

i wondered if they might have tried to protect it somehow but then these are very speacialized controlers so the only real protectin they might want is trying to hide their ideas from a potential competitor then that would make sense.

but with any of that i should be able to just duplicate the ROM memory and have it work ?? yes ??

i do not want to debug or decipher just duplicate ROM to replace my fried ROM

no other chips between the data path and ROM/MCU

- SN74LS377 (D-Type Flip-Flops)

- 74LS251, (data selector multiplexer, 3 state out)

- 74LS28J, (2 input positive NOR buffers )

- 4049

the ROM Addr 0-7 is connected to the inputs 1D,2D etc.... of 3 diff SN74LS377 (D-Type Flip-Flops) the output of the Flip-FLops 1Q,2Q ... connect to a Static Ram chip's (SRM2016) Address lines and the SRM data lines are connected to the I/O port 1 of MCU p1.0-7

the LS377 has connections to the other chips around the MCU also eg. (74LS251, 74LS28B, 4049, others)

i posted a PIC in alt.binaries.schematics.electrionics of all the chips involved. i know it is not a schematic but it shows the chips i am talking about.

thanks again donald for all the help, robb

First thanks for all the help,

I have new ROM dump below (bottom of post)using a chip suggested by Ian an D87C257 this loks better if you could take a peek and comment i would appreciate that/

i don't want anyone shooting in the dark i want to make it bright and clear

i give the information i have first and then whatever will help you experts help me i try to provide as best i can.

I originally tried to approached this as simple as possible... copy ROM(orig) image , burn ROM(new), test ROM(new) on the working board

so that i would not need to worry with encryption and adress shifts and all the other tricks of the trade.

so now the ROM reader is suspect

thanks again, robb

D87c257 read....

---------------------- :020000040000FA :1000000002096FC0D0C0E0020173FFC0D0C0E0029F :1000100001BEFF30B202D22A32FFFFC0D0C0E0C022 :1000200082C083C000904058E531540F204C073007 :1000300045036001040423F893F58DE80493F58BE0 :10004000E542540790405093F8E541540793C44863 :10005000758360F0206F26D294E530758350F0E50B :100060002D543F7041C245C28E206F19205D1E1273 :100070000F39D000D083D082D0E0D0D032204DD9FB :100080007530FF80D4205C4C12154A80E5E5422093 :10009000E002C294E530758350F080D6E54120E05F :1000A000F353307780EE14601314147002D24CE5D1 :1000B0003130450C540F600215313164316480B227 :1000C000C4B53109C24C1046F1D24580ED104CEA5E :1000D000053180E6104DC5E520440F20E701C4F549 :1000E00030758DFBD28ED24D53200F80854320F08A :1000F000E52D543F603AFDF5317842306F0118E646 :1001000030E0021531E531C313B4020575310A80C0 :100110000DC394035001E4C3139246C4F531E6D2F3 :100120004C20E009C24CED1460031201641201641A :10013000208E20306F06E530C4B53009758DFF750F ........... snip ........... :10096000D23D22D23C22E0540F24F650F3808D7504 :1009700090CC797E7802760008D9FB75B8E175894C :1009800011758CFE75880575A8867583607444F0B2 :1009900075835074FFF530F0758D88D28ED2137543 :1009A000530AD28C120D60308FFA7583507477F52C :1009B00030F07455758360F0C28F758D88120D60AC :1009C000308FFA906007E030E002D20A756DE0D215 :1009D00014D2131230A8754400C22C121808C28E0B :1009E000C28FD2AB1229FCD2192019F82018F5A217 :1009F000B492E0A2B592E1F45403F52B3014102028 :100A0000200D204A472010031218EAC214C2131204 :100A100029FC304A082011E4200DE1800DE5445402 :100A2000F0B4F006202FD52010D220182AD293D26D :100A300092C295C2D3C2D4A2B492E0A2B592E1F41C :100A40005403FAE52B5403B5023980B02011BC20C1 :100A50000DB91231A780B4D2193014057553008036 :100A60009B3018C93092298043501E120CAEEA60A8 :100A700030B4030A205A12D25A1213157403120DFD :100A8000428006EA20E0E250E2532BFC422B21FC9C :100A9000C293D295C291E543B4569CC290D2A8802D :100AA00096305AE5C25A120EA5E480DD7552A0C2F6 :100AB00093D292C20A304102D291E543B45602D297 :100AC00090752E00750600D215754D00120CAEC241 :100AD00089D2A8301E04C22AC21EC25A205646E538

The address is obviously being latched in the ROM. Otherwise, when the

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I was wondering about that.

I have not found a data sheet for the D23256.

Is the OP trying to insert a 27256 into the same socket that the D23256 came out of ??

That would explain why the 27256 would not work in the same socket.

donald

when the

the D23256

socket.

was

Hello OP here, The reason for trying to use a 27c256 in place of the D23256AC is.....

that was some advice given on the MCU-Mall user forum where they sell lots of cheap chinese ROM programmers.

one of the regular posters thought 23256 was just a read only / mask rom version of the 27c256 ? so i went with that.

i kind of half convinced myself that the latching mechanism could be superceeded with a fast enough 27c256 operation ????

the 23256 was 150ns and many 27c256 are 50-90 ns so that 27c256 is ready long before the read occurs ??? that was my thinking

thanks for any help , robb

robb

For such a scheme to possibly work, your replacement ROM has to be a lot slower, not faster. A 150ns ROM means the MCU has to wait at least

Andy,

I do not believe this is 100% correct.

You are correct that the data is stable 150ns or 90ns after the Chip Select line is stable. The data will stay stable as long as the CS line and address lines are stable.

The CPU involve is an 8051. The date of the circuit the OP has (1985) is old enough to believe that it is a 12Mhz processor with an internal divide by 12.

So the memory cycle time of the CPU is 1us, the cpu will "wait" most of that 1us before it latches the data from the ROM.

I'll check an old 8051 data sheet later, but a 90ns ROM will work just fine.

doanld