Hello everyone,
I am troubleshooting a professional coffee machine (Melitta C35) control board based on the Freescale ColdFire MCF5232CVM100 (BGA package). The system is currently stuck at the initial "Please wait" screen and does not proceed to the main menu.
Hardware Details & Measurements:
- MCU: MCF5232CVM100 (ColdFire V2 Core).
- Flash: cFeon EN29LV160 (TSOP-48).
- Power Rails:
- VDD (Core): Measured 1.6V on the micro-capacitors surrounding the MCF5232.
- VDDIO/Periphery: Stable 3.3V found across the board.
- Analog/Other: 5V rail is present.
- RTC Battery: Measured 3.29V (stable).
- Debug Interfaces: The board provides a standard 26-pin ColdFire BDM header AND a 10-pin (2x5) Mini-BDM connector.
- Service Port: External 9-pin RS-232 (DCE, Female).
Symptoms:
- On power-up, the display initializes and shows "Please wait".
- The board has a Reset button that toggles the 3.3V line, but the MCU remains in the same "Please wait" state after reset.
- I measured -5.6V on the TX pin of the RS-232 port, which indicates that the line driver is powered and the UART is likely initialized by the bootloader.
Questions for the community:
- Given that the display shows "Please wait", is it safe to assume the MCU has successfully initialized the FlexBus and started executing code from the external Flash?
- What are the typical reasons for a ColdFire V2 to hang at this stage? Could it be a checksum mismatch in the Flash or a timeout waiting for a peripheral (I2C/SPI)?
- Does the presence of both 10-pin and 26-pin BDM headers imply any specific debugging priority? Is one more suitable for a USBDM interface to dump the cFeon Flash?
- Are there any known "trap" states or Double Bus Fault indicators I can check via the BDM pins without a full debugger?
I have ordered an FTDI USB-to-RS232 adapter to capture any potential boot logs. In the meantime, I would appreciate any insights into the boot sequence or common failure points for this MCF5232-based platform.
Best regards, Alex
Specifically, I'm looking at the CSET14A controller and the power management section (marked with inductor "150"). I noticed some suspicious residue around the pins of the small ICs in these areas, which might be a lingering effect of the previous steam exposure
module? If this peripheral fails to respond during the boot sequence, could it cause the system to stay on the "Please wait" splash screen indefinitely?
I have thoroughly cleaned all ribbon cables, connectors, and PCB contacts using 99% Isopropyl Alcohol. Additionally, I replaced the CR2032 battery on the display module; the old one was at 3V, and the new one is stable at 3.3V. Unfortunately, these steps did not change the symptoms—the machine still hangs at the "Please wait" screen.
I’ve closely inspected the display module, and it appears to be a sophisticated Single Board Computer (SBC), likely i.MX-based. I’ve attached photos of both sides of the PCB and the interface panel.
- RS-232 (DB9 Male) which is connected to the main fascia RS232 via an extension cord
- Ethernet (RJ-45)
- USB Type-A (Host)
- Mini-USB (Service/Debug)
- SD Card Slot (Internal), but no any card in it...
- Given this array of ports, which one is most likely to provide a full boot log if the main ColdFire board is silent? Is the RS-232 on this display module typically the system console for the OS (Linux/WinCE)?
- In your experience with NXP/Freescale industrial designs, does the Ethernet port usually have a default static IP for diagnostic web-interfaces?
- Could the "Please wait" message be a local splash screen from the Display SBC itself, indicating it is waiting for a "ready" handshake from the ColdFire MCU via the communication bus?
- UART Activity: I measured the voltage on the TX pin of the RS-232 service port. It shows a steady -5.6V relative to GND. My understanding is that this indicates the line driver is active and the MCU’s UART module has been initialized by the boot code/firmware.
- Current Strategy: Iprior of probing the high-speed bus, I have ordered a high-quality FTDI (Ugreen) USB-to-RS232 adapter. My plan is to use PuTTY (115200 8N1) to capture any bootloader logs or error messages that the MCF5232 might be spitting out during the "Please wait" hang.
- Peripheral Status: I've been informed by a Melitta specialist that this specific "Please wait" state is often a software deadlock caused by communication loss between the CPU board and the Power/Display boards (likely I2C or Serial timeout).
Similar chip to one of the ones we use (MCF5235).
(Good luck with iFixit, Alexander!)
It is very likely it is running code from the Flash. It has to do that to get the initial message onto the LCD. That is unless there's another CPU hiding on the board that does that (and that's unlikely). That's a "Bottom Boot" Flash, so the bootstrap is probably in the first sector. This is usually protected (somehow). The chips I'm used to have a hardware pin to do that. That chip needs software protection, and then overriding that by putting a high voltage on the Reset pin in order to change it.
It is probably running the Bootstrap - that puts the "Please Wait ..." up as a Splash Screen and then gets on with finding, verifying and running the code that is in the rest of the Flash somewhere. Obviously that isn't happening.
So the clock, power supplies, data bus and most of the address bus are being tested and seem to be working (or you wouldn't get that screen). There's very little you can do at this point.
I'd suggest getting an oscilloscope - give up now if you can't get one of these. Check the RAM and Flash Chip Selects. If they run for a short while then stop, then something is making it crash (like a double-bus fault). Except this (no external signals) is also possible if the Cache is enabled and it is in a loop waiting for something to happen where that loop is in Cache. It is also likely that it is running the Boot using the 64k of internal RAM rather than having to use the external one. I assume the big chip with "DAA" on it is the RAM.
If the firmware is corrupt and failing a checksum you would hope it would SAY that on the screen.
You could get a debug pod and plug it onto the 26-way port ... except this isn't 2004 (when that chip was released) and so the original debug pods aren't available any more. You could use a P&E Multilink, but that's quite an investment to make for this problem.
The top of the screen shows "SW Version V7.18". That's interesting. If it ran a separate Bootstrap and App Firmware, then they're usually different versions, and I'd expect that to say "Boot Version" or "Loader Version".. "SW Version" implies it only has one block of software and not two. Or a programmer didn't think of that distinction.
It might be waiting for the hardware to do something, but I can't think of what.
Have you tried getting a board from Melitta? Is it too old and out of support?
How old is it? The only date I think I can see is 2010.
Tom
> I’ve closely inspected the display module, and it appears to be a sophisticated Single Board Computer (SBC), likely i.MX-based. I’ve attached photos of both sides of the PCB and the interface panel.
There's a large chip under a "QA passed" sticker that obscures the part numbers. The only thing I can see on it is "CHINA" and I didn't know the i.MX chips were made there. Can you peel off that sticker and see what it really is? Also, can you read the three chips around it (two Flash and a RAM or vice-versa)?
Yes, that Splash Screen is most likely being shown by that board while it is waiting for the other one to talk to it.
They'll be talking over some sort of shared bus. From most to least likely I'd say SPI, I2C, Serial, CAN, parallel-port, shared memory. Some designs use Ethernet, but the MFC5232 doesn't have that controller.
So the port isn't working, or the software that drives that port isn't working due to something being wrong somewhere. Which could literally be anywhere.
I'd normally say "find what ports (on the MCF5232) head out to the video card", but the MCF5232 is a BGA chip, so you can't follow pins with a meter or visually. Likewise trace back from the video card to see what connects to pins there. The "Video Card" seems to have a lot more on it that the product seems to need. It may be made by someone else. See if you can read all the writing on it (that text on the left edge) to see if you can find a manufacturer or part number. If it is sold by someone else, you might be able to get a data sheet for it.
You need an oscilloscope (real or PC-based) to look at all the signals on the connector to see if you recognise bit rates, frequencies, protocols and so on. Don't get a very cheap one as they don't have the bandwidth. You need at least 50 MHz.
I think I said before, see what's running (chip-selects from the CPU to memory chips). If the MCF5232 had a "double bus fault" it will be halted. It should be running something otherwise. If it did halt, it is likely there's a watchdog to try and reset it out of that.
Tom
photo of the ColdFire PCB for reference.- All those small 8-pin networks near the connectors and under the MCU are actually 10k Ohm resistor arrays (marked "103").
- In the center of the board, right between the MCF5232 MCU and the interface routing, there is a 74LCX162 (16-bit low-voltage buffer/line driver) chip.
Hi Tom and the Community.
I have some updates... Full WinCE Boot Logs Captured — Hardware Specs and Handshake Failure probably Identified...
About the display unit identification. It is the Garz & Fricke NESO 5.7 display module: https://imrad.com.ua/userdata/modules/productFiles/1sASRkzV_GF_NESO_Series_Manual_V1.4.1.pdf?srsltid...
- Main MPU (under the sticker): Freescale/NXP i.MX27 Multimedia Applications Processor (ARM926EJ-S Core), Silicon Revision PASS 2.1.
- RAM Chip: 128 MB MDDR (Mobile DDR SDRAM) operating on a 32-bit bus.
- NAND Flash Chip: 256 MB STMicroelectronics NAND02GR3B2.
- EEPROM: Atmel AT24C at address 0x00:0xA0.
- RTC: Philips PC8563 (Log shows: «RTC time is not valid! Please check your battery», which explains my need to replace the CR2032, though it doesn't cause the lockup).(BTW. First connection to the ColdFire port was not successful (no logs with any baud rates, conencted directly or via a null-modem)).Display RS 232 was responsive, it passed its hardware verification completely. Windows CE 6.0 boots up smoothly, mounts the flash partitions, and successfully executes the Autostart sequence. I tried to fix the problem via the firmware updating. I attempted a simultaneous firmware update to v7.20 for both boards using a 2GB FAT16 USB stick (for the display) and an SD card (for the ColdFire access board), as recommended by a Melitta technician. The display successfully initiates the official installer: USB-MStick\Autostart\Updater.exe.Here is the exact point of failure from the PuTTY log:==========================================================autojob: execute: USB-MStick\Autostart\Updater.exe
URM_IOControl: unknown IOCTL 0x010303ff
GFV_IOControl: unknown IOCTL 0x010303ff
SerOpen+
SL_SetRTS+
SL_ClearRts+
SL_SetRTS+
SL_ClearRts+ - ==========================================================Right after this, the display throws a "Communication Error! Closing application..." window.As the log clearly shows, the Updater.exe opens the serial port successfully (SerOpen+) and repeatedly toggles the RTS (Request to Send) line (SL_SetRTS+ / SL_ClearRts+), trying to handshake with the ColdFire board. However, it receives absolutely no CTS (Clear to Send) response back from the ColdFire PCB. The transmission line is dead silent.(Note: Earlier in the log, I noticed Serial diag is enabled. Disabling UART1!. I verified that booting the machine completely headless without the debug laptop connected yields
- the exact same communication error).
- Power Status on the ColdFire PCBI have thoroughly re-checked the power rails on the lower ColdFire MCF5232 board multiple times. All logic voltages are present, completely stable, and within spec:
- VDD (Core): 1.6V
- VDDIO (Periphery): 3.3V
- Analog Rail: 5V
This rules out a dead buck regulator, a blown fuses, hard short circuit on the MCU power lines, etc. The ColdFire MCU is fully powered. - Preliminary Conclusion & Questions:
- The i.MX27 display module is 100% healthy, but the ColdFire MCF5232 board is completely mute on the communication bus. Since the lockup occurred probably after an emergency power-off the machine, I suspect the high-load inductive kickback during the hard disconnect physically fried the RS-232/CAN transceiver IC on the ColdFire side, or the MCF5232 is stuck in a permanent Double Bus Fault / hardware freeze.Tom, knowing that we have an i.MX27 PASS 2.1 architecture attempting an RTS handshake with fully powered MCF5232 logic rails:
- Does this behavior point to a classic interface transceiver failure on the slave side?
- Are there any specific pins or status registers on the MCF5232 I can safely probe with a multi-meter to check if the core clock is running or if the chip is entirely halted?
3. Do I really need for a high frequency oscilloscope, or, it would be useless in this situation?Best regards,
Alex
Please note that all of these interface components are NOT located on the ColdFire module itself. Instead, they are situated on the main motherboard/baseboard, positioned directly next to the ribbon cable connector that runs out to the display module.
- High-Speed CAN Transceiver: It is a Texas Instruments SN65HVD230 (marked VP230 / 07M AFR2 in a SOIC-8 package). This 3.3V CAN transceiver connects the ColdFire module's CAN controller directly to the inter-board link .
- Line Protection: Assisted by the adjacent JY2501 SMD transorber/filter array and 330 Ohm matching resistors (marked 3300), all sitting right at the ribbon cable traces.
- Peripheral Mapping: Further down the baseboard, the system utilizes the Texas Instruments 74HC165 8-bit shift register to handle localised sensor signals.
I think in can confirm that the inter-processor link is purely CAN-bus based. When the i.MX27 display installer loops on SerOpen+ and SL_SetRTS+, it is attempting to open a virtualised serial driver mapped over the hardware CAN controller.
Great find regarding the i.MX27 and the CAN bus architecture! You're absolutely right—the i.MX27 display probably doesn't have built-in CAN capabilities and communicates with the baseboard exclusively via standard serial UART lines. The TI VP230 CAN transceiver I found is likely part of the internal ColdFire MCF5232 subsystem (using the integrated FlexCAN controller) for controlling peripheral sensors, boilers, grinders, etc. on the high-voltage side. I assumed that since the crash occurred precisely during a boiler overheat, this fault could potentially have destroyed this VP230 chip. But it kept shutting down several times in a row after the same problems before I resoldered those two components, and then turning back on again and again... As for the "Communication error! Closing application" window—yes, it only started appearing after I loaded the v7.20 firmware files onto a USB/SD drive. When booting without New firmware SD and USB inserted, the system simply hangs silently on the "Please wait" splash screen, which aligns perfectly with your theory that this is the final stage of OS initialisation, awaiting confirmation from the main application. I really appreciated your advice to check if ColdFire is working at all before touching anything. I'll check the static DC voltage on the 74LCX162 buffer and the microcontroller reset lines to make sure it's not frozen at the hardware level. To answer your question, yes, it was indeed an Australian passport! My location is the Gold Coast, QLD. Do you have any information If there's any hobbyist or engineer in the Gold Coast/Brisbane area with an oscilloscope who wouldn't mind helping me test a crystal oscillator and logic lines? I'd be happy to fill him/her/them with a few gallons of cold beer, tequila, cognac, diesel, etc. – whatever they prefer
But if no one so dedicated is found, I'll have no choice. To buy an oscilloscope is the solution only.
However, I doubt it's available in our Jaycar "toy stores"
Another question concerns the technique for working with such microscopic chips. The probe needles can be even thicker than the pins... When the device is turned on, any imprecise touch can instantly destroy the microchips...
And if you're sure that a forced power-off couldn't cause this problem, I completely don't understand what happened. Why was everything working fine before replacing the MOC3082 and the thyristor, but afterward, the "Please wait" message appeared? There's no logical connection.
Thank you one`s again, Alex
p.s. I have 3 different manuals for NESO Series display units, but they`re in PDF format. I can`t upload them here. Is there a way to share PDF with the community?
You can buy a handheld single-channel oscilloscope for $40. I wouldn't recommend it (I've got one as a toy) as they're only good for 200 kHz. But for $63 you can get one that goes to 5MHz. That's useful for this sort of thing.
On to your observations. Well done finding the display board, manufacturer and getting the boot log. Also taking all those photos.
Unless you have the same bootup-log from a good one (showing it doing something different) I wouldn't take much notice of that RTS/CTS stuff. They haven't been used for communication since about 1970. It is more likely the RTS output is connected to an LED or something. Given you know the video board, can you get the user manual and schematic to see where the RTS output of the CPU really goes?
I doubt a "hard emergency power off" could do anything. The only way a "spike" should get from the high power side to the logic would be through a blown power supply. These things are well isolated by design, and Melitta knows what they're doing here.
You might be like the "drunk looking for his keys under a lamp-post because the light is better there", in that you're checking what you can fix rather than what might be wrong.
Unless you have a good unit "doing an RTS handshake" or have documentation saying that's what is happening, I wouldn't read too much into that RTS thing. That's just the last thing the OS Startup does before running the "Application Code".
The "Communication Error! Closing application" is new. Is that new with the software update?
CAN? The i.MX27 doesn't support CAN and neither does that display board. Where did that come from?
On the subject of checking the "74LCX162 ", you could measure the voltages on all pins and compare them whth what you'd expect with that set of inputs from the Data Sheet. It would be WAY easier to use an Oscilloscope though! You don't have to BUY one, just find a hobbyist nearby with one and borrow it (and them).
But first you need to work out if the Coldfire is running at all, or running and crashing. Ditto, Oscilloscope.
OK, there's a CAN Transceiver. But since the Display Board doesn't support CAN, that's not likely to be the problem. Unless the Coldfire talks to something on the baseboard (over CAN) which converts it to serial for the display board. That's unlikely as the Coldfire has plenty of serial ports. How can the link be CAN based when there's no CAN port on the video card? Have I missed something here?
Say WHERE you are geographically and someone might help you out. Was that an Australian passport in one of the photos? Which CITY are you in?
- The "Blown" ICs: The scary black craters that initially looked like blown-out silicon chips were actually rock-hard, carbonized, baked-on coffee crusts sitting directly on top of the components.
- The NE555 Timer: As you can see in the attached macro photos, the NE555 timer chip had several pins completely bridged together by a thick, bright green copper-oxide encrustation and baked coffee mass. This can effectively short the logic signaling gates and degraded the traces over time while the unit sat there under logic voltage.
- Passive Components: Several nearby SMD resistors and capacitors were completely fused together under a blanket of this conductive coffee-steam grime.
Before doing any heavy cleaning, I checked the main logic power rails to see if any chips were internally shorted to GND. The results are an absolute triumph for Melitta’s hardware design:
- 5V Rail (Fuses): Completely clean. Capacitors behave perfectly, charging up to infinite resistance.
- 3.3V Rail (Baseboard MLCCs): Clear. Measures pure infinity relative to GND.
- 1.6V Core Rail (ColdFire Module): Probed the decoupling capacitors right next to the MCF5232 BGA chip. It measures a stable 173 Ohms to GND, which is the exact expected static resistance of a healthy, un-shorted CPU core.
- Probing the Cleaned NE555: After clearing the green copper-oxide bridges, I measured all pins (2, 3, 4) relative to GND (Pin 1) and directly between each other — they all read solid infinity in all directions! The internal silicon gates survived perfectly.
Tom, you were 100% right — the hardware isolation on these boards is tank-like. The MCU and logic survived. There is a chance to hope that the system dropped into the infinite "Please wait" and "Communication Error" loops because the conductive coffee-steam bridges clamped the shared logic signaling lines, cutting off the inter-board dialogue.
How the main (motherboard) looks likeHow the main (motherboard) looks likeHow the main (motherboard) looks like
I`ve circled some visible issues with redI`ve circled some visible issues with redI`ve circled some visible issues with redAlex Congratulations. Conductive liquids and electronics don't mix. The main problem with this sort of damage is usually electrolysis. Copper moves from exposed tracks, pads and pins towards the nearest power rail pads. Tracks under solder mask are OK as long as that isn't breached, but pads and vias form an opening in the mask where the copper can get eaten away. You can also have tracks eaten away UNDER components. Let us know if you get it working again.
This came up in a search. It says conductive dendrites are the biggest problem. It would also be worth following the references to Louis Rossmann's channel:
https://medium.com/@tom_a/corrosion-in-printed-circuit-boards-e85f7e84bb15
A 555? Seriously? Is it a "Classic NE555" type or a CMOS variant? The originals generated terrible power supply spikes; the CMOS ones were better.
Tom