MTS2000 Green LED Stays On at POST

The General forum is where users can discuss any topic regarding Motorola communications equipment - hardware, software, etc. There are also several focused forums on this board, so please take the time to ensure that your questions doesn't fall into one of those categories before posting here!

Moderator: Queue Moderator

Post Reply
rodell
Posts: 127
Joined: Tue Apr 06, 2004 8:51 am

MTS2000 Green LED Stays On at POST

Post by rodell »

I've got a MTS2000 on the bench - It is a pre 5.42 formware vintage, and, I think someone did a labtool job on on it, tweaking some parameter somewhere. Clearly, it isn't toolproofed in the "classic" sense. The POST just never finishes, no beep at all. Attempts to read the radio just time out.

Is there any reset for the controller, short of reflashing it to something else? Any hidden handshakes?

Rob
Northeast Massachusetts
AEC
No Longer Registered
Posts: 1889
Joined: Wed Dec 22, 2004 7:56 pm

Post by AEC »

If the controller never ends a POST, and the LED remains lit, it appears as though your controller is hosed with a dead micro.

Check all the connectors on the cover flex, and the jumper assy that ties the RF board to the controller, if the pins or flex are loose or even slightly pulled out, this may be the actual cause of your trouble.

Look for the obvious first, then dig a little deeper later.

As always, check for cold/poor solder joints on the connectors and controls as the CPU looks at these to ensure they are in operational condition then outputs a 'good' response if all is well.

If you DO get the radio to respond, but see codes on the display, here's a list you can check to see what those codes mean.

FAIL 01/81: FATAL! External ROM/flash checksum error...Bad ROM data, Defective ROM

FAIL 01/82: FATAL! External EEPROM checksum error....Bad external CP data, defective external EEPROM

FAIL 01/02: NON-FATAL External EEPROM checksum error....Bad external CP data

FAIL 01/84: FATAL! External EEPROM checksum blank...Unprogrammed external CP data

FAIL 01/88: FATAL! External RAM error...Defective RAM

FAIL 01/90: FATAL! Hardware failure..Defective I.C

FAIL 01/92: FATAL! Internal EEPROM checksum error...Bad internal CP data, defect. microcontroller

FAIL 01/12: NON-FATAL Internal EEPROM checksum error...Bad internal CP data

FAIL 01/94: FATAL! Internal EEPROM checksum blank...Unprogrammed internal CP

FAIL 01/98: FATAL! Internal RAM error.......defective microcontroller
rodell
Posts: 127
Joined: Tue Apr 06, 2004 8:51 am

Post by rodell »

Looks like the controller is no good. I can't find any real problem under the microscope, touched up a few things here and there with special attention to the connectors. Same problem.

As a learning experience so, and so I can report back, is it possible, with anything you can do with labtools, to cause this kind of problem and put it in this state? (Not a flash tool.)

Rob
AEC
No Longer Registered
Posts: 1889
Joined: Wed Dec 22, 2004 7:56 pm

Post by AEC »

I doubt toolproofing could cause that sort of malfunction, usually, the radio simply refuses to power up if it's been toolproofed.

That locks out the controller from use and will not recognize a valid POST and activate, and turns the radio into a brick/paperweight.

I sure wish someone had a valid work around for toolproofing, that would certainly be useful for many with costly paperweights sitting on desks across the nation.

One more reason to despise Circle-M!
OX
Posts: 1321
Joined: Tue Sep 04, 2001 4:00 pm

Post by OX »

Actually, if you read the information on the Batlabs site, there is a very accurate description of what happens when a controller becomes "toolproofed".

The controller upen boot will go into F01/93 because of an internal checksum failure caused by using Depot RSS which does not recalculate the "toolproof" checksum. The controller is put into an idle state. It still will talk to the outside world via the SB9600 port on the side of the radio. You can read and write the radio without any other issues. But until the checksum gets fixed, the radio will always go to F01/93. All other operating functions stop working.

All it takes to repair the F01/93 is to write a good saved codeplug back to the radio without packing the data (done from lab). You lose all changes made by the Depot tool which makes using it pointless. This codeplug has to have the same serial number, model number, flashcode, options plus a few other parameters that weren't released contained in the codeplug. So only one codeplug will work.

You can also flash upgrade the radio. This will default the radio's codeplug to what was flashed and you can then program the radio again. You can also restore the radio if you can get it back to the "initialized" state. I don't have the tools to do this with but I know they exist. Someone could theoretically create a CBI image as an s-record or binary file.

I actually F01/93'd a MTS and someone worked with me through email to fix it. They actually used the 838 labtool to reset the parameters and the radio worked after sending the codeplug. I intentionally lost their contact info for their safety and privacy.

So by toolproofing the radio, it is still usable to the right person with the right tools.

As for your problem, it sounds like there is a problem in the boot ROM. It isn't accessible by the codeplug programming. Flashing the radio might help. Personally, I'd send it in for a depot trip so that you know it's fixed correctly.
Post Reply

Return to “General Motorola Solutions & Legacy Radio Discussion”