MCF5232 stuck at boot / "Please wait" screen on Melitta C35 controller 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 Macro shots of the touch frame and suspected areas Hi everyone, I've taken some macro shots of the capacitive touch frame for a closer look. Context: This "frame" board is mounted directly around the main display. Its primary role is to handle additional touch-sensitive buttons for the machine's interface (e.g., Stop, Steam, etc.). It connects directly to the display SBC. Suspicious areas: 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 Ive performed a deep cleaning of these specific zones with 99% IPA with heat drying, but no positive outcome again. I want to rule out any I2C bus "hanging" caused by micro-leakage or oxidation under these components before the FTDI adapter arrives. Does anyone recognize the 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? Thank you, Alex UPDATE - Hardware maintenance performed and discovery of Display SBC ports Good morning. I have an update regarding the maintenance performed and some new findings on the hardware. Maintenance Update: 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. Discovery of Display SBC Module: 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. The Display Module features a significant "arsenal" of connectors: 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... The board is populated with a BGA MCU, NAND Flash (NAND02G), and Micron DDR2 RAM. Questions for the community: 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? I have ordered some extra necessary parts: DB9 female gender changer, Null-Modem adapters for the FTDI cable to interface with these ports. Any advice on how to leverage this "arsenal" for deeper diagnostics would be greatly appreciated. Best regards, Alex Re: MCF5232 stuck at boot / "Please wait" screen on Melitta C35 controller Thank you for your insights, Tom While I don't have a compatible oscilloscope on hand yet, I’ve performed some additional measurements that might be relevant: 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). If the serial console remains silent after the adapter arrives, I will proceed with a USBDM debugger to inspect the CPU status registers as you suggested, or look into getting a portable oscilloscope to verify the FlexBus activity. I will update this thread as soon as I have the first logs from the console. In the meantime, does the -5.6V on TX suggest to you that the MCU has at least successfully reached the stage of peripheral initialization? As for the last questions from your post., yes, this machine is 2011 year of manufacture. I`m surprised, but parts and service are still available. Even this particular module is available, but the price range is much higher than this unit value... Moreover, nobody knows right now if it`s really faulty... Thank you one more time, Alex Re: MCF5232 stuck at boot / "Please wait" screen on Melitta C35 controller 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 Re: MCF5232 stuck at boot / "Please wait" screen on Melitta C35 controller > 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 Re: MCF5232 stuck at boot / "Please wait" screen on Melitta C35 controller An idea with the at-fault component... 🙂 I am attaching a photo of the ColdFire PCB for reference. I have closely inspected the board and checked all the SOIC/TSSOP components. Interestingly, there are no dedicated RS-232/CAN line driver transceivers (like MAX3232 or TJA1050) near the interface connectors. Instead, the board uses a direct-drive topology with passive protection: 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. This confirms the direct-drive architecture. The UART/bus signals from the MCF5232 go straight through the 74LCX162 buffer and the 10k resistor arrays into the ribbon cable to the display. Given the emergency high-load shutdown event, it's highly probable that the inductive kickback blew the 74LCX162 buffer chip, acting as a fuse and completely isolating the ColdFire UART lines from the display, while leaving the main power rails (5V, 3.3V, 1.6V) intact. Do you think a blown 74LCX162 buffer matches the "SL_SetRTS+ with no CTS reply" symptom we are seeing in the i.MX27 logs? Is there any simple way to check this version? Thank you, Alex Re: MCF5232 stuck at boot / "Please wait" screen on Melitta C35 controller 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=AfmBOoo4vya1_YCFjSLfTK2z55_qKcgmDmTJcvGvXnBsYd0cuEHwuVjK I received my FTDI RS-232 adapter and successfully captured the complete boot logs from the Garz & Fricke NESO 5.7 display module via the UART debug port (X551, 115200 8N1). The logs provide a precise diagnostic picture, and we no longer need to peel off any "QA Passed" stickers, as the RedBoot and Windows CE kernel outputs have given us the exact hardware specification of the display SBC. 1. Display SBC Hardware Specification (from Logs) 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 PCB I 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 Re: MCF5232 stuck at boot / "Please wait" screen on Melitta C35 controller CRITICAL UPDATE: Baseboard Interface Analysis with Exact IC Markings I have captured macro photos of the communication interface section (attached). Crucial Topology Clarification: 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. This means this section acted as the frontline physical shield between the inter-board cable and the plug-in ColdFire CPU module [I]. Here is the exact component mapping of this interface stage: 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. Given the emergency power-off, the inductive kickback may damage the TI SN65HVD230 (VP230) CAN transceiver at the connector entrance. When this chip fails internally, the differential lines go dead, resulting in the silent bus and the immediate "Communication Error" we observe in the Windows CE updater logs. Do you have any advice on measuring passive diode drops on the CANH/CANL pins of this specific VP230 to ground, just to determine and localise a fault, please? It looks like the are lots of potential components in the row with the fault suspicion. A big question how to sort this "head ache" out Alex
記事全体を表示
