Users may not create topics, posts, or private messages containing or relating to the following material (especially pertaining to Motorola copyrighted software, unless you want Motorola to come along and shut this site down):

  • Listing for sale or trade of, or links to sites offering for sale or trade of, or giving away, Radio
    Service Software (RSS) or Customer Programming Software (CPS)
  • Profanity, pornography, defamation, or slanderous remarks directed towards any individual or entity
  • Commercial advertising (except in the Batboard Vendors forum, as approved by the Admin/Mod Staff)
  • Any other items which may be deemed as offensive

If any topics, posts, or private messages containing or relating to the aforementioned material are brought to the attention of the Admin/Mod Staff, they will be deleted.

Additional FAQ items appear here in Forum Rules. Please review them for posting guidelines and further clarification.

R2001D checksum warning

This forum exists for the purposes for discussing service monitors (This includes but is not limited to Motorola, HP, Aeroflex, GD, etc). Additional topics allowed include test procedures, interpretation of test results, where to find information about specific tests, antenna VSWR, return loss testing, duplexer and filter alignment, etc.

Moderator: Queue Moderator

boffin
New User
Posts: 3
Joined: Mon Dec 02, 2019 1:28 pm

R2001D checksum warning

Postby boffin » Fri Dec 06, 2019 5:27 am

Hello,

I'm based in the UK and very much new to the Motorola world. Motorola radio kit seems to be a fairly rare beast around these here parts.

So, thanks to a well know auction site, I now am a somewhat confused owner of a R2001D set (actually it's a R2010D/HS but the cellular card is only fit for banging against my head when I get stuck - so it's coming in handy).

The unit currently powers up and reports that there is a checksum error in ROM M5. As a starting point I've pulled ROMs and backed them up.

Through sheer luck I've managed to get the unit to boot up and operate. I disconnected the NV Ram battery. I tried to boot it up with ROM M5 removed.
None of which had any effect. I then burned a copy of ROM M4 and put it in the M5 socket, hoping the checksum might be per ROM and it would pass that test.

It didn't pass the checksum test but it has allowed me to continue and the unit operates. Looking at the dump of M5, it seems it relates tones, which I've not attempted to use (and why most other functions seem to operate). I guess I got lucky!

Can anyone confirm the checksums for the ROMs?

The system reports "SOFTWARE VERSION (??) 48" and version "4.06" for all the MAIN ROMs.

Here are my checksums:-

Code: Select all

md5sum *.BIN
62a32e4429ad665bd00176f4fc730578  u45.BIN
0e63790b5877b52c6625cb4039a9502b  u6.BIN
196c1ab76fc3fbda29ef16fa86214c16  u7.BIN
6f3ee1af9613ac84f41b6e53407d6f2f  u8.BIN
b7f70a1e72ec3e6e7c03209b08a78e99  u9.BIN

Now I've got it running, there are a few more issues (an intermittent INT/EXT 10 Mhz reference switch had me foxed this morning) but before I delve too deeply it seems sensible to get to the bottom of the ROM issue.

I have checked the address and I/O lines on the ROMs (which are common between them) and these check out OK. I'm assuming enable on ROM M5 is also OK given the behaviour changes dependant on the contents (or lack thereof) of the socket.

Thanks for everyone's worldly knowledge.

Cheers!

Steve.

boffin
New User
Posts: 3
Joined: Mon Dec 02, 2019 1:28 pm

Re: R2001D checksum warning

Postby boffin » Sat Jan 04, 2020 10:50 am

An update on where I am with this issue.

Thanks to jry, I now know my ROM images are intact and the checksums are correct. So the EPROM is fine. For good measure I've replaced the EPROM but no change.

Each of the five ROM sockets have common supply, address and data lines. To eliminate any of these being an issue, I used a couple of DIP24 sockets to allow me to mount U45 (M5) in the U6 (M1) socket and vice-versa. The only line unique to each ROM is the CE line on pin 20, so I lifted pin 20 on the new sockets and tacked it to relevant pin 20 on the PCB. With U6 in the U45 socket and U45 in the U6 socket, I still received a checksum error on U45.

I intentionally modified each of the ROM images to introduce a checksum error (by changing a single character in a text message). With these modified images, a checksum error was reported in each ROM (M1,M2,M3,M4 and M5). That seems to confirm that the message does actually relate to checksums and the checksum process is working correctly (as best I can tell).

So, I decided to look at the CE line on M5. This is driven by an AND gate (U47) and an address decoder (U51). I note someone has already removed these from my PCB and installed the ICs in sockets. So it seems I'm following someone else's investigation from 20 plus years ago! I replaced both the ICs again for good measure. No change.

I then lifted Pin 20 on M5 again and wired it directly to the output of U47 (to eliminate any PCB issues). No change.

I've checked continuity between the ICs and this appears to be as expected.

There is another address decoder in front of U51 - U23, so I've replaced that (and fitted a socket). No change.

So, all the ROMs have the right images. The checksum process on ROMs M1 thru M4 work. The supply, address and data lines on M5 are okay, pointing towards an issue with the CE line on M5. I've now replaced all the obvious ICs associated with the M5 CE line.

I've looked at the CE line of M5 on the scope (and compared it to that of M1) and they both look OK.

Remember, the contents of M5 does affect the functionality of the unit. With a genuine M5 image, it freezes on the checkerboard after the checksum warning. With the image of M4 flashed to M5, the checksum error still occurs but then the unit does operate (although with slightly odd behaviour, which is to be expected given them firmware is incorrect). This does confirm it was actually reading M5 (at least in part).

My next step is to obtain a logic analyser.

Can anyone suggest what I might have missed? I wonder if the M5 checksum error message is somehow misleading?

Cheers,

Steve.

jry
Posts: 408
Joined: Fri Feb 06, 2004 3:14 pm

Re: R2001D checksum warning

Postby jry » Mon Jan 06, 2020 8:49 am

I would pull the cellular ...you may want to install the jumpers on the backplane to bypass but not sure it's always needed without looking at the SM

Usually the cellular option is installed in either the A12 or A13 slot and in the case of a 2010D you should have a blank/jumper board installed as well as the cellular in one of those two slots.

The blank has some jumpers which you set depending on the slot it is installed in so you may just want to jumper the empty slot accordingly at the backplane

boffin
New User
Posts: 3
Joined: Mon Dec 02, 2019 1:28 pm

Re: R2001D checksum warning

Postby boffin » Tue Jan 07, 2020 12:00 pm

Thanks for the suggestion.

Yes, I've pulled A12 board and have the A13 jumper board installed. I checked the jumpers on the A13 board as they have a couple of positions but all four relate to the analogue side of the unit - AM MOD, 1Khz SINE, EXT MOD and INT MOD input and output lines.

If I have the A12 board fitted, then a firmware status "99" does display the details of the A12 board.

One thing I did discover is that the checksums are not (just) stored in the individual EPROMs. I'm guessing there is a list of all the checksums in rom U6 (M1). I've found that swapping U7 (M2) and U45 (M5) in their sockets still allows the unit to self test. In this configuration I get a checksum error in M2 and M5. So it looks like the unit checksums each EPROM based on socket location and not just the EPROM contents.

Not sure that really helps me fix the problem but it was interesting!

Cheers,

Steve.


Return to “Test Equipment & RF Equipment Alignment”

Who is online

Users browsing this forum: No registered users and 1 guest