Mcf5407 won’t boot

[Rbilliexx]

I have a synth with a mcf5407 that won’t boot. When power is applied, the data and address lines quickly show waveforms then go dead. This happens every time I cycle the power. The ram has been replaced,the cpu clock looks ok, I don’t see any ripple on the 3.3v or 1.8v lines. The cpu is a know good one. I don’t have any shorts on the data or address lines. Any idea what else I could check? The ps has been tested on another motherboard and it works fine. The boot rom has also been verified on another motherboard. The boot up diagnostics fails the sram memory test. (A blinking led instead of solid and doesn’t go any further) Thanks for any replies.

[TomE]

Please supply more details on the hardware design. The MCF5407 as an internal DRAM controller, and can also control external ROM (which you're booting from) and external SRAM. It also has 2k of internal SRAM, so when you say "it fails the SRAM memory test" it isn't clear which one it failed. I'm assuming it has external SRAM and that's the test that's failing, but you should confirm that. When I say "SRAM" I mean the external one.

The good news it that the CPU is in a QFP package, so you can get to all the pins. You won't have any BGA problems with that package. The CPU has 32 address and 32 data bus pins, and 8 chip-selects. I'm assuming that's what the Boot ROM and SRAM are connected to. I would expect the ROM and SRAM to be connected to the same Data Bus pins and the same Address Bus pins.

So if the ROM works and the SRAM doesn't, that limits where the problems can be.

The CPU handles 8, 16 and 32 bit devices. Is your ROM 8/16/32 bits? Is your SRAM 8/16/32 bits? If they're different, and the SRAM is "wider", then the problem might be with the data pins on the SRAM that don't connect to the ROM. The ROM might only be using a small range of address lines, so a high address line might be bad, and that might fail the SRAM test. Does the firmware check the ROM (with a checksum)? Can that fail?

How "wide" (8/16/32) is your ROM and SRAM? How "large" (kbytes/Mbytes)?

Check all the address lines while it is booting. Look for bad signals. Likewise all the data lines (although floating states are expected, you should see clear high and low levels). Check read/write> Check the chip selects.

Tom

[Rbilliexx]

Thanks for the reply. This motherboard has the MCF5407 with an 8 bit 29LV040B eeprom, two 16 bit sram chips. When I power it on, it flashes the synth’s leds once and just the backlight to the LCD screen lights. I put a scope on the data pins of the bios and I get a very quick waveform that looks like what I normally see on a working board and then it stops with a solid 3.3v. It is very quick. The unit has a diagnostic program built in and you access it by holding 3 buttons down while powering it up. The first thing that is run is the sram test. It lights three groups of leds – the first is one sram, the second the other, the third is an address line test. Once all three light solid, the display shows the diagnostic routines that can be run. This board just lights the first and second buy they flash which indicated a memory failure. I replaced both sram chips, the eeprom with another known good one, the cpu was replaced with a known good one. I checked each data line and address lines for shorts to ground or to each other. The quickness of the shutdown makes me keep looking to a shorted component but everything seems ok. I have a working board along side this one that I compare readings. I removed various chips on the data lines in case one of them was loadfing it down. The board has 5 DSP chips but I’ve had them on the board and off the board. The original failure of this board was one of the DSP chips was shorted internally and got very hot real fast. I’m really surprised it can do a memory check since it appears to be shutting down in a fraction of a second.

[TomE]

That many chips removed and replaced, I'm impressed at your dedication (and courage). It sounds like the people trying to repair the Alesis Andromeda. Except that one uses an MCF5307 (the "next one down"), 3 SRAM chips and one DSP(?). There might be some hints here if you haven't already read through it:

https://gearspace.com/board/electronic-music-instruments-and-electronic-music-production/985035-trou...

Do you have the schematic or does the manufacturer consider that to be "secret"?

The best thing for you to try would be to do what "Peter Sobot" did on his Andromeda. It has the same BDM (Background Debug Mode) port on the MCF5307 as you have on the MCF5407, so it would work on yours:

http://blog.petersobot.com/fixing-the-andromeda

If you have a working debugger, you can examine the Flash contents (technically not quite an EEPROM), compare with the same thing on the good one, and read and write the SRAM manually. You can also find out where it crashes or aborts the SRAM test, and so get a good idea of WHY it stopped. That works you back to the fault. Debuggers are expensive, and require a lot of software to work, so Peter read the specs and programmed an Arduino to do the work for him. And then published his work so others could use it.

So you've got an MCF5407 based synth. Something like this?

https://electro-music.com/forum/topic-69081.html

OK, so how to go about fixing it. I'd go the debugger route if possible. If you want to really do this "the hard way", try getting a logic analyser and capture the CPU bus. Then manually decode the instructions and see why it fails that way. I've done that, a very long time ago when it was easier to just clip onto the CPU's pins to read those signals. You can even do that with an oscilloscope "one trace at a time, one signal at a time, tabulate, rinse and repeat". This CPU also has Data and Instruction Caches. So if they're enabled during startup (they shouldn't be) you won't see what it is doing on the external bus.

I'm guessing the Synth was working until the DSP got hot. So the most likely thing is that repairing that caused the fault you're now seeing. Or that fault damaged something else. So take more measurements around there. Just measuring power-off resistance of all signals to ground and comparing with a good one might help.

Here's a hint. Get two multimeters. Put one on Volts, the other on Ohms and connect them together. You're measuring how many volts the one measuring resistance uses. The trick is, if you can find a multimeter that uses less than 0.5V then it can measure in-circuit resistance while not getting fooled by all the diodes inside the chips. Then take measurements in "Diode Mode" (which uses a higher voltage and does see the diodes) and compare them between boards as well. Use both polarities of measurement. Measure resistance to ground and to 3V3. Check as many adjacent track for shorts as you can reasonably do.

OK, so you've got a high speed CPU, two SRAM, one FLASH, 5 DSP and lots of other stuff on the bus. If they're following the rule books, that bus has to be buffered. The Address Bus coming out of the CPU might be directly connected to the FLASH or SRAM, but there might be buffers between it and elsewhere. Likewise there should be bidirectional buffers on the Data Bus. It is possible that when the DSP blew up it shorted part of the bus and that might have taken out one or more of the bus buffers. So check the signals on both sides of all of them. Are any of them hot? Do you have an FLIR?

> I’m really surprised it can do a memory check since it appears to be shutting down
> in a fraction of a second.

The CPU is running up to 162MHz. The SRAM is probably running a 54MHz clock at 6 clocks per cycle. So it can read or write 20MB/s. It probably has 0.5 or 1M of SRAM. So it could read all of it in 1/20 second. It is probably stopping on the first SRAM failure, so that could be in milliseconds.

These things start running using the SRAM inside the CPU, and only use the external SRAM once it has been tested. I'd suggest you get a two (or more) channel oscilloscope and connect one probe to the SRAM Chip Select. Trigger off that. Set up an external oscillator to continuously reset the CPU (makes it easier than turning it on and off). Probe the address lines during the SRAM CS and watch the CPU "walking" up through the address lines on the SRAM. You should be able to record them all counting up. The address where the SRAM test stops should be "instructive". You can watch the SRAM read and write data on the data bus during SRAM CS assertions. You might see what's wrong there.

Read through the MCF5407 User Manual cover to cover. That may give hints on what it does and what it might do wrong that you hadn't thought of.

Of course check power supplies, AND EVcc (3.3V), IVcc (1.8V) and PVcc (1.8V). Check CLKIN and BCLKO (frequency, stability).

Edit: Just reread "two 16 bit SRAM chips" are they on the same 16-bit data bus or one on the lower 16 and one on the upper 16? D24-D31 is working (as that's what the Flash is on and can be read). D16-D23 might have a problem (if SRAM is 16-bits) or D0-D23 if SRAM is 32 bits wide. Check the byte-lane select signals too.

Tom

[Bio_TICFSL]

Hello,

Check the power supply I do not see another option here. Here is the user manual of MCF5407.

https://www.nxp.com/docs/en/data-sheet/MCF5407UM.pdf

Regards

[Rbilliexx]

A second known good power supply does the same thing.