Avid Pre

[sr1200]

I have an avid Pre (black face) that just died last night during a session. On boot the unit just goes into 8.8.8. on the front panel. I've spoken to two shops both say the front panel board is no longer available. Just wondering if anyone has any thoughts on being able to salvage the actual preamps from the unit or if theres any way to turn this into some kind of non digitally controlled unit. Seems like a big waste.

 

[sr1200]

Ive gone down the list of authorized repair centers for avid. Most of them said they dont deal with avid anymore lol. The ones that do wont deal with this unit. Bummer.

 

[juanito2008]

Did you checked the power supply ?

 

[sr1200]

Did you checked the power supply ?

Power supply is fine. This is a well known issue with the eprom on the front panel. Something (unknown) causes it to wig out and lose its programming. Avid refuses to release the software or pin out on the chip to reflash it.

 

[nashkato]

is the eprom socketed and / or is the chip made unreadable ?

 

[sr1200]

the eprom is surface mount so it would be difficult but not impossible to reprogram. From what i was told from a very agitated repair shop that is no longer dealing with avid, the ability is there, but since avid wont cough up the software that needs to go onto it, they couldn't do it even if they wanted to. Im not sure if you can rip the code from a working chip or not, they didn't say.

 

[ruffrecords]

Power supply is fine. This is a well known issue with the eprom on the front panel. Something (unknown) causes it to wig out and lose its programming. Avid refuses to release the software or pin out on the chip to reflash it.

Does it have a part number on it?

Cheers

Ian

 

[DaveDC]

The Avid PRE used a TI MSP430F133 microcontroller with internal flash, so there is no EPROM to reprogram. You would need to re-flash the microcontroller using its JTAG interface. TI made a special "MSP-FET" programmer tool for this, so you'd need that in addition to a copy of the compiled source code. That code, of course, is unobtainable. However, the MSP430 runs on +3.3 volts which is generated locally by a subregulator. You might want to check the health of that +3.3V rail. Looking at the TI datasheet online, you should check for 3.3 volts at pins 1 and 64 of the 64 pin LQFP package.

 

[DaveDC]

Oh, and replacing any large electrolytic caps on the front panel PCB might bring it back to life. I would expect one on the +5V rail and another on the +3.3V rail. These would be for bypassing the digital logic, so the cap value is not super critical. You just want to get rid of any caps that may have shorted internally.

You can also poke around the microprocessor and its crystal with a scope to see if there is any activity. Pretty much any activity on the pins will indicate that the processor is alive and executing code. It may be that the processor is okay but just has a problem "talking" with its front panel LEDs and relay drivers. In that case, just look up the datasheets of the nearby ICs and scope their inputs and outputs, replacing any failures.

 

[DaveDC]

Finally, as for reading the code from a working unit and programming it into another unit, doing so would depend on whether or not Avid programmed the MSP430's security fuse or otherwise secured the device. Securing the device essentially disables the JTAG port and thereby disables any code reading.

 

[sr1200]

@DaveDC thank you so much for the input. Once i get the band i have in the studio out, i will start poking around the unit a bit more. Right now its sitting on the junk pile shelf in the shop. The rails off the PS looked ok, but you're right that doesn't mean something else down stream didn't crap out and isnt getting signal. The caps should be an easy enough first pass. Thank you again!

 

[DaveDC]

@sr1200: No problem. Please post back here about what you find. I was curious and looked at the MSP430F133 datasheet and found that its minimum flash memory retention time is 100 years at room temperature, so it is unlikely the flash aged out. It is possible that it exhausted its 100,000 flash write cycles if it was programmed to store its state periodically and often. I don't remember if the PRE remembered its state or not. Unfortunately, the engineer who designed the PRE and wrote its code died a few years ago, so we may never know.

 

[sr1200]

It did remember its last on state. I definitely didn't turn it off and on 100,000 times through.

 

[DaveDC]

I was thinking that it might have been programmed to save its state on a timer event, like every minute or something like that. That could eventually wear out the flash. But this is pure speculation on my part. I'm just looking for something to explain the cause of what you said is a known failure mode for this device.

 

[sr1200]

I replaced the electrolytics that were near the 3.3 and 5v test points. The 3.3 reads 3.287 and the 5v is reading 4.83 which if its using 5v for logic might be a little low?

 

[DaveDC]

The 5V logic is not particularly sensitive to is power supply voltage, so 4.83v will be okay. The 74HCT245 octal bus transceiver that connects to the MSP430 is rated down to 4.5V. And in case you were wondering, the 74HCT245 only needs a minimum of 2.0V for a valid logic HIGH, which is how the 3.3V MSP430 can talk to it without violating any logic level rules.

Do you see any activity on the microprocessor? You should see activity if you probe the crystal Y1 (or the ends of the two caps fight next to it) with a scope. You won't see perfect logic signals, but at least one of its terminals should be wiggling a little bit at 8 MHz. If it is wiggling, then the MSP430 is at least trying to run.

Next, you should also see sporadic activity at TP1 which is located near U5 on the front panel PCB. This is the (active-low) WRITE pulse that latches the data from the parallel bus (buffered by U2) into the many 74HC574 octal D flip-flops scattered throughout the unit. You should also see activity on the address and data busses themselves, which are connected to the input pins of 74HCT245 U5 (address bus) and U2 (data bus). The MSP430 first asserts address and data out its I/O ports to the ribbon cable that goes to the main board. The address is decoded on the main board to select one of the 74HC574s that drive the relays, etc. Once the data and address are stable, the MSP lowers and immediately raises the WRITE signal. The rising edge of the WRITE pulse latches the data into the selected 574 which in turn energizes the relay indicated by the data. So each pulse on TP1 represents one 574 being written to. If there is no activity on TP1 in response to front panel action (gain change, etc.), then it is likely that the MSP430 has a corrupted flash and can't successfully run its program. If that is the case, there is little that can be done besides flashing a new (unobtainable) code image. You could also rewrite and flash the code yourself from scratch. This might sound a bit crazy but it would not actually be all that difficult.

Let us know what you find.

74HCT245 datasheet:

https://www.ti.com/lit/ds/symlink/sn74hct245.pdf

 

[sr1200]

had a pipe burst with the cold weather in the shop over the weekend. No damage thankfully, but cant get to my bench/scope at the moment since we had to move tons of stuff to get to the pipe for repair.
Not sure ill be able to test the TP1 thing since the front panel is kind of bricked at the moment with the 8.8.8. I can't select a pre or change gain. I still need to check to see if there's any logic flowing at the MSP430F133
working off this datasheet:
https://www.ti.com/lit/ds/symlink/msp430f133.pdf
I assume i can check pin 8/9 for signal from the clock/crystal?

 

[DaveDC]

Bummer about your busted pipe!

Yes, that is the correct datasheet. You want to look at the high speed crystal XT2 on pins 52 and 53. You should also see activity on the I/O ports P4 and P5. You can also have a look at the signals on the front panel pushbutton switches and see how they respond to keypresses. I'm just guessing about how the software might work, but it is possible that a key is stuck down and that the software is hung up waiting for for the key to be released. There are more keys than the processor has I/O ports, so they are likely connected in some kind of row/column matrix. There would then be some evidence of a matrix scanning process going on. This where having a working unit to compare to would be useful. If you had a working unit, you might then be able to extract the software from it, replace the (possibly) defective CPU on the bad unit, then re-flash it, assuming the JTAG fuse is not blown (see page 32 of the datasheet). Do you see a JTAG port anywhere on the board? It is usually a 14-pin header with nothing connected to it. That is where you'd connect the flasher tool.