Author Topic: IFR1200 CPU Card Corrupted -Dead --Need Help (Read 4094 times)

try2fix · « **on:** June 17, 2019, 07:26:20 pm »

Hi, hope someone can help, I have read that the eproms inthe IFR1200 can get corrupted over time - So Copied and burnt eproms from a working IFR1200s , put the new eproms in & the cpu card is now bricked- I put the old eproms back in with no change, I took from another IFR1200s a good working CPU card and put in the eproms and it is bricked now --- is there some kind of blanking program that has to be run before changing the eproms ? -- I removed the batt and discharged the caps to try to clear and still no go - the display is blank when the cpu card is not working, all you will get is @@@@@@@@@@@@@@@@@@ flash when you power down the unit - I put a good CPU card in and the unit works great --but now I have a few dead IFR1200s as I have Bricked there cpu card - any one got any answers please, Thanks

fzabkar · « **Reply #1 on:** June 18, 2019, 05:46:49 am »

I can't help, but maybe it would help to see your EPROM dumps. Perhaps they contain a unique data block??? Are they special devices, or just off-the-shelf parts? Are there any other non-volatile memories in the unit?

try2fix · « **Reply #2 on:** June 18, 2019, 12:43:01 pm »

Thanks, the eproms are 27c512.
I am trying to send the file for you to read but it is a .bin file and I have not figured out how to convert it to a acceptable one for the form--I have a lot of learning to do and helps are welcome

try2fix · « **Reply #3 on:** June 18, 2019, 12:50:37 pm »

here is what the files look like from the IFR1200S - There are Two 27c512 chips , bottom and top

try2fix · « **Reply #4 on:** June 18, 2019, 10:44:17 pm »

Here is the file from IFR1200 super s - it is somehow corrupted or has caused the CPU board to lockup...? it is on a 27C4001 eprom - no successes in it working after I had programed another chip and plopping it in
I have tried on a few IFRs and they work fine untill I put in my locked up cpu cards. What makes it worse is I borrowed a friends IFR and locked up his cpu card.... there must be some simple way of getting them to wk again... those of you that are good with hex let me know if it looks corrupted. I have also pulled out the SRAM on the 1200s but cpu still not talking... I am thankful for all and any help ...new to the forum so hope I am doing all correct

TheSteve · « **Reply #5 on:** June 18, 2019, 11:14:03 pm »

So you've had the same issues with the IFR S and the Super S with different type/size eproms? Perhaps your eprom reader is not getting good dumps.
Assuming others have posted eproms dumps from the 1200 series have you compared them?

try2fix · « **Reply #6 on:** June 19, 2019, 12:31:52 am »

I have never seen anyone post a eprom file so I cannot compare, the super s I just read and programed another eprom as I could not fine any one to lend me theirs to read it as a known working file, so it could be corrupted over time but I figure not as when I borrowed a good working 1200s from a friend and read his eproms ,then put the copied ones into his board it reacted the same as the dead/locked cpu board in the super s unit ........... if you see any post that has files let me know and I can try to compare but I think now it is something that IFR put into a program to crash it as I took another good cpu board and put in the eproms from my friends ifr cpu board and now it is locked/dead, so I put my original eprom back in, no change --I cannot figure as 27C512 eproms are read only what is programed onto them, very frustrating as I have to get my friends IFR back to him in working order before he needs it.
I did a read, program and then verified the chip but kinda out of practice for eprom stuff so could well have messed up the eprom but putting the old back should have brought it back to life----- about 25 yrs back I remember the c band sat boards that you had to put in a blanking chip and then you could drop in the new eprom program and that was with the 27c series eproms... maybe IFR made the same thing

? must be someone around that knows

TheSteve · « **Reply #7 on:** June 19, 2019, 03:02:35 am »

Had a look at the files you attached. They are all corrupted, there is no valid data in them.
Unless the corrupted data caused hardware damage(unlikely) you need to get some good images and verify your programmer is operating properly.

fzabkar · « **Reply #8 on:** June 19, 2019, 03:59:05 am »

The data repeat in blocks of 0x100 bytes. That is, the data at addresses 0 - FFh is the same as the data at 100h - 1FFh, 200h - 2FFh, and so on until address 0x10000. Then there is a new 0x100-byte block which repeats in the same way until address 0x20000, at which point a third 0x100-byte block appears and repeats until the next 64KB boundary, and so on.

This suggests that address bits 8 - 15 are stuck. Bits 0 - 7 and bits 16+ are OK.

try2fix · « **Reply #9 on:** June 19, 2019, 05:11:35 am »

Thanks , I will follow up and read them again to see if I have done something wrong, just learning all about how to read these chips, thanks

fzabkar · « **Reply #10 on:** June 19, 2019, 08:40:26 am »

I'm betting that your programmer is faulty, possibly a bad octal latch or transceiver. Could we see the programmer's PCB?

try2fix · « **Reply #11 on:** June 20, 2019, 01:18:58 am »

Here is A pic of my programmer, it is a "Universal EPROM pic flash mpu Programmer"
I trided to program a few more chips and I get an error now for each one, I have to figure out what is not setup correct, but still does'nt make sense that the cpu card would not work after I put the originals back in. I'll send out a new file of the other cpu card original chip when I get it read off and you can let me know what you think. thanks

try2fix · « **Reply #12 on:** June 20, 2019, 02:20:57 am »

Okay here is the Eprom file that was from a working IFR1200 CPU board untill I replaced the chip from the other cpu board - then I put this original back in and dead cpu board.
So the file is the original, let me know if it looks that way. Thanks

fzabkar · « **Reply #13 on:** June 20, 2019, 03:03:18 am »

It appears to be a Willem knock-off, PCB version 5.0E.

I examined some Willem circuit diagrams, but I can't come up with a fault scenario which could account for the apparent corruption we are observing.

BTW, the programmer does have a self test facility whereby you can send a user selected address and data combination to an empty ZIF socket. You can then verify the pin voltages with a DMM.

try2fix · « **Reply #14 on:** June 20, 2019, 05:14:27 am »

okay help me out here the chip has a hex number 73E1 printed on it - assuming that is check sum -so I do a checksum but I do not know what I should be in (checksun-16/32/CRC-16 ...ect) - so I am using CRC-16 as it gives the closest of 7F8C --I am using HxD Hex Editor - so I did blank some chips and reprog and finally got it to program without errors using to 27512 seting vs 27c512 -I don't know why but maybe you can educate me about that-but the chip verified as same --but still wondering why the check sums are different:73E1 on chip vs 7F8C using Hex editor.
let me know if you see that I am doing sum thing wrong, Thanks

fzabkar · « **Reply #15 on:** June 20, 2019, 06:06:32 am »

Your last dump is just like the others, ie there is a block of 0x100 bytes which repeats from start to finish.

As for checksums, there are numerous algorithms in use. In any case it wouldn't be possible to identify the algorithm until we are certain that the hex dump is good.

TheSteve · « **Reply #16 on:** June 20, 2019, 07:53:34 am »

Try2fix it is a long shot but if you're in the Vancouver area I can help read/erase/program the eproms.

try2fix · « **Reply #17 on:** June 24, 2019, 07:41:36 pm »

Thanks, I am in Alberta so that is still about 14hrs drive so don't think I will head over to your place yet, but thanks, maybe you could help me just figure out the eprom stuff - I have been doing tests by reading a eprom that is in a working unit, then I take a erased eprom and program it, compare it by reading it a couple times, ball the same, then I put it in to replace the original and no go, put the original back and it works -- I go and compare again and they r the same

what do you think i am doing wrong ? thanks

try2fix · « **Reply #18 on:** June 24, 2019, 08:00:10 pm »

Yes it says Willem Eprom prog
okay help me out to know what to type in to test the pinouts when in the test mode as I am not sure what pin to be testing and when/what...thanks

CJay · « **Reply #19 on:** June 24, 2019, 08:33:35 pm »

If your EPROM programmer has a problem with stuck address lines it will read the original ROM incorrectly but worse, it will program the fresh ROM with the incorrect data and then it will verify it as correct.

You need a sanity check, find someone with a different EPROM reader/programmer and have them copy the ROM.

try2fix · « **Reply #20 on:** June 25, 2019, 01:19:46 am »

Thanks for all the help so far - new findings are that I got most of all the cpu boards going by swapping processor sram and eproms around and found out that it looks like my new eprom reader programmer has somehow fried the 27c512 eproms i read!---how can it do that, i was just reading- any thoughts would be great --I also have a old programmer but no info on it , any one know what software runs this thing ? Thanks

try2fix · « **Reply #21 on:** June 25, 2019, 01:51:14 am »

Okay can some of you look at these 2 files- The First I got read off a few months back by a friend 3hrs drive away, I have now read that same chip with my reader and it is sure different, Any help would be great to know if the first file looks corrupted and then the second file to the first to try to determine what pins are not working on my reader, Thanks

fzabkar · « **Reply #22 on:** June 25, 2019, 01:53:14 am »

That looks like a dedicated programmer for 8748 and 8749 microcontrollers (and others).

fzabkar · « **Reply #23 on:** June 25, 2019, 04:13:34 am »

Quote from: try2fix on June 25, 2019, 01:51:14 am

Okay can some of you look at these 2 files

I only see 1 file. BTW, why can't you see for yourself that the data repeat in blocks of 0x100 bytes?

try2fix · « **Reply #24 on:** June 25, 2019, 04:58:33 am »

Thats different, I loaded 2 files , I guess only one when threw , Here is the first one again- I got a lot of learning ahead
- on reading the files I don't know what I am doing to know that it is a repeat or what, thats why I ask the experts, you all that work with this kinda stuff. Thanks for the info on the old reader, looks like it won't help me for this project

try2fix · « **Reply #25 on:** June 25, 2019, 05:16:18 am »

boy I must be on another setting or something as I looked and I cannot see any repeats. I am useing Hex Editor but just learning as I go, sorry for my errors

TheSteve · « **Reply #26 on:** June 25, 2019, 05:30:12 am »

The last file has valid data in it. Although it isn't even half full - hopefully that is just because they overspec'd the eprom size required.

try2fix · « **Reply #27 on:** June 25, 2019, 05:39:11 am »

Does this last file look like there is something that would be repeating in its code so it would not work as there is no life out of the cpu card when I put it in. I have no other cpu cards like this one so I have no way of switching out the rom with anouther at this time- I did sw out the procesor (N80C188) and proved that it is working.

fzabkar · « **Reply #28 on:** June 25, 2019, 06:00:01 am »

The latest dump looks OK, although I haven't worked out the checksum algorithm. The easiest way to see the differences is to ZIP each file. Your bad dumps will produce very small ZIPs due to their mostly redundant content.

Your good dump has a lot of text strings before 0x30000. The first two bytes (EB 02) decode to an x86 JMP 0104 instruction, so it could be that the CPU is an Intel chip of some sort. I suspect that bytes 2 and 3 may be the checksum (since the JMP instruction jumps around them).

That said, I can't see anything in the dumps that would enable me to suggest where to start fault finding your Willem programmer. Perhaps someone else can see something.

Edit: I posted my reply before I saw your last post.

try2fix · « **Reply #29 on:** June 25, 2019, 04:59:53 pm »

Thanks, the cpu is N80C188 and on the rom chip [M27C4001] is a labeled "F080-2200-100 v1.12 U3" I am thinking maybe the correct check sum should be F080 and it is version 1.12 but the other who knows.
Please if someone has some of these files can you send the hex so it can be compared to know what is corrupt in mine, I have about 4 or 5 different versions of the files but I have to now figure out what is wrong with my reader as it reads out wrong values.

try2fix · « **Reply #30 on:** June 25, 2019, 10:54:04 pm »

Good news I got my eprom reader fixed now I just have to figure out what pins it took out of the 2 27c512 chips I read --so I managed to copy and write to a blank 27c512 of a working version 3.0 - and it works on the ifr now...so here is the file of a working unit, if any one can determine what got corrupted on the version 7.1 chips it would greatly help me to get this working again.
The 7.1 version is what I am trying to get working as it has all my tracking options-this is on 2 chips.
The 6.1 version & 7.1 Version some how got corrupted and will not work after I removed them from a working ifr1200s and read them.
The 1.12 version is from a ifr super s with all the options but it to is corrupted.

So I took the version 6.1 chip erased it and programed it with all zeros as I thought if there is a problem with the chip some should not program..well all programed perfect, so I am really confused how the eprom could have got corrupted in me reading it as it sure seems to work fine now -I'm sure you guys will let me know where I error
Thanks for all the help.

CJay · « **Reply #31 on:** June 26, 2019, 06:24:15 am »

Quote from: try2fix on June 25, 2019, 10:54:04 pm

Good news I got my eprom reader fixed now I just have to figure out what pins it took out of the 2 27c512 chips I read --so I managed to copy and write to a blank 27c512 of a working version 3.0 - and it works on the ifr now...so here is the file of a working unit, if any one can determine what got corrupted on the version 7.1 chips it would greatly help me to get this working again.
The 7.1 version is what I am trying to get working as it has all my tracking options-this is on 2 chips.
The 6.1 version & 7.1 Version some how got corrupted and will not work after I removed them from a working ifr1200s and read them.
The 1.12 version is from a ifr super s with all the options but it to is corrupted.

So I took the version 6.1 chip erased it and programed it with all zeros as I thought if there is a problem with the chip some should not program..well all programed perfect, so I am really confused how the eprom could have got corrupted in me reading it as it sure seems to work fine now -I'm sure you guys will let me know where I error
Thanks for all the help.

What was the problem with the EPROM programmer that caused it to read incorrectly?

try2fix · « **Reply #32 on:** June 26, 2019, 07:02:36 pm »

Quote from: CJay on June 26, 2019, 06:24:15 am

Quote from: try2fix on June 25, 2019, 10:54:04 pm
Good news I got my eprom reader fixed now I just have to figure out what pins it took out of the 2 27c512 chips I read --so I managed to copy and write to a blank 27c512 of a working version 3.0 - and it works on the ifr now...so here is the file of a working unit, if any one can determine what got corrupted on the version 7.1 chips it would greatly help me to get this working again.
The 7.1 version is what I am trying to get working as it has all my tracking options-this is on 2 chips.
The 6.1 version & 7.1 Version some how got corrupted and will not work after I removed them from a working ifr1200s and read them.
The 1.12 version is from a ifr super s with all the options but it to is corrupted.

So I took the version 6.1 chip erased it and programed it with all zeros as I thought if there is a problem with the chip some should not program..well all programed perfect, so I am really confused how the eprom could have got corrupted in me reading it as it sure seems to work fine now -I'm sure you guys will let me know where I error
Thanks for all the help.

What was the problem with the EPROM programmer that caused it to read incorrectly?

there was a jumper in the wrong position, I can't figure out how it corrupted the rom, but that being said I am now looking for some rom files if anyone has ver6.1 and 7.1 that would be a great help

fzabkar · « **Reply #33 on:** June 27, 2019, 07:02:02 am »

The file which looks OK, but isn't OK, probably has bit or byte errors. Did you set the Vcc to 3.6V or 5V?

try2fix · « **Reply #34 on:** June 27, 2019, 04:17:23 pm »

"Did you set the Vcc to 3.6V or 5V? "
5v
So I copied and programed a few chips to test and all is working on the programmer now

try2fix · « **Reply #35 on:** June 29, 2019, 05:08:48 pm »

Okay so maybe some of you that understand ziping files to gether to find common trends might be able to tell me what the common diff is on these files that work vs the corrupted ones that do not work.There are 2 eprom chips on the board U3 & U4. Still trying to figure all this stuff out, Thanks

fzabkar · « **Reply #36 on:** June 29, 2019, 10:46:01 pm »

Are these checksums printed on the EPROM's original label?

try2fix · « **Reply #37 on:** June 30, 2019, 07:51:23 pm »

Are these checksums printed on the EPROM's original label?

Yes, That is correct

TheSteve · « **Reply #38 on:** June 30, 2019, 08:11:42 pm »

If you perform a checksum 16 on the "working" files the digest value will match what is on the label. I verified both files with Hex Workshop.

try2fix · « **Reply #39 on:** July 01, 2019, 12:01:31 am »

okay, thanks. So the corrupted files have no pattern in regards to the wking ones -just trying to figure out how to fix a bad file without knowing what it is/was originally

fzabkar · « **Reply #40 on:** July 01, 2019, 02:36:44 am »

Launch HxD and open a non-working hex dump.

Got to offset 0 and drag your cursor over the 0x100 bytes of data between
offsets 0 - FF. Those 0x100 bytes should be highlighted.

At the bottom of the screen you should see ...

Now go to Search -> Find, select Datatype -> Hex-Values, place your cursor
in the "Search for" box and then type Ctrl-V. Then click OK.

Hit the F3 key to search for this block of data and keep hitting the F3 key
to repeat the search. Now do you see the problem?

To compute the checksum for your hex dump, select Analysis -> Checksums ->
Checksum-16 -> Entire File.

try2fix · « **Reply #41 on:** July 01, 2019, 04:18:27 pm »

okay, well that sure helps when you walk me trough the steps, thanks

try2fix · « **Reply #42 on:** July 04, 2019, 04:38:12 pm »

I have IFR1200 Super S with corrupted eprom in the cpu card, looking for someone with the hex file to help me get this back up and running

try2fix · « **Reply #43 on:** July 09, 2019, 04:15:39 pm »

I been asked for pics of what the dif is on the new IFR1200s to super s vs the older---well this is some what I have found -see word doc for the pics
THe Hi loop module is dif - I do not have picture
The CPU board has what I have seen 2 types for the 1200s and a 3rd for the super s -see word doc for pics on the later 2
The Rx Audio PC Board & the Interface board are dif-see word doc for pics

-I am sure there are a lot more of you out there that know a whole lot more than me, but this is what I have found for those of you that wanted pics, have a great day.
I am still looking for anyone that knows what is wrong with my super s file ---look at it and let me know , thanks


EEVblog Main Site	EEVblog on Youtube	EEVblog on Twitter	EEVblog on Facebook	EEVblog on Odysee

Author Topic: IFR1200 CPU Card Corrupted -Dead --Need Help (Read 4094 times)

Share me