Page 1 of 1
MTS2000 Green LED Stays On at POST
Posted: Sat May 27, 2006 6:08 pm
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
Posted: Mon May 29, 2006 12:21 am
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
Posted: Thu Jun 01, 2006 7:03 am
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
Posted: Thu Jun 01, 2006 11:02 pm
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!
Posted: Fri Jun 02, 2006 6:46 pm
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.