EEZ Bench Box 3 (BB3) and beyond...

[prasimix]

You can now follow @Jan28's progress with the electronic module in the BB3 EEZ-DIB form factor also on GitHub: https://github.com/fietser28/EL-Load

Fantastic work!

[prasimix]

@goran.mahovlic from Intergalaktik.eu finalized STM32H7 module in CM4 form factor for BB3-CM4 module. Project is now available on GitHub: https://github.com/intergalaktik/bb3-cm4/tree/main/EEZ_BB3_CM4_H7

[Lion_Tamer]

Hi All

I am finally getting round to finishing the assembling of some more modules for my 2nd BB3 and have one that ia throwing an error message, I haven't managed to find a list of the possible error codes and explanations anywhere so thought I would ask on here.

The module in question is a DCP405 R3B3 and the message that I am getting is is "Ch1 IOEXP fault match detected" with a continuous rapid beeping and inability to close the message, this has also sometimes caused the BB3 to enter and exit standby repeatedly even though the power on self checks come back as okay.

Does anyone know what the code set criteria is for this fault code? I assume that it is one or more of the input signals to IC14 that it is moaning about but not sure which one.

For info incase it matters - I am using an R3B3 MCU with firmware V1.7.6

Thank you

Jem

[prasimix]

Check if your PCB has JP2 on bottom side, and if yes then cut it and check once again. Be also sure that I/O Expander IC is soldered correctly.

[Lion_Tamer]

Yes I had JP2 on the bottom - I have another 3 of these modules to complete - will I need to cut it on all of them?
The soldering on the IC looked okay but when I tested between adjacent pins there was a short between pins 1 (~set_DP) and 2 (OE) - must have been a really small whisker as I still couldn't see it at 30x magnification - Looks like my next investment might have to be a microscope.

[prasimix]

You can cut JP2 if you wish, that is RESET line that comes from MCU and in some rare situation could generate instability hence it's removed in the latest revision.

[IanJ]

Hi,

Really like the retractable feet on my BB3 and want to use them on a home made design for something else......where can I get them?

BOM just says:
A-951-A-0-G-0
Adjustable feet (pack of 2) Altinkaya, Turkey

Ian.

[HwAoRrDk]

These?

https://www.altinkaya.eu/shop/a-951-tilt-foot-set-4pcs-set-729#attr=1072

It seems you can buy direct.

[PlainName]

Sorry for necro post - if there is a better place I couldn't find it (which probably attests to the robustness of the BB3!).

Got a BB3 with two DCP405 modules. One of them I've been using at 5V for a while (albeit on and off) and today I am using the other one at 12V. A bit earlier I noticed the CC LED of the unused module flickering slightly, and it's got worse until now it is on constantly. The output is not turned on, but if I do turn it on the LED goes out,.

Turning the 12V module on or off doesn't affect the LED, and the CC LED on that channel doesn't come on when the output is off.

Is this something I should be getting worried about?

[prasimix]

What is the version of your DCP405 module: r2B11 (green PCB) or r3B3 (blue PCB)? The later is better produced and generally you shouldn't be concerned about this behavior.

[PlainName]

It is an original green, as supplied with your two-channel kit in 2020 (gosh, that's years ago). I'd love to have another box to put around a blue one (or two), but cost of living has trumped that idea so far

Glad to know it is ignoreable, at least for now.

[loglow]

Hi. I backed the original crowdfunding campaign for the bare boards kit and I've just gotten around to doing the assembly. I'm having some frustrating trouble with the MCU, and I could use some help.

Timeline:

- Damaged one leg of IC3 during assembly. During removal, one pad de-laminated from the board (IC3 pin 122).
- Ordered replacement IC3.
- Installed replacement IC3. Installed tiny jumper wire in place of missing pad (see attached photo of repair).
- Completed MCU board assembly.
- Successfully flashed processor via dfu-util.
- Connected display and aux-power board.
- MCU did not boot. Standby light would stay on. No beeps.
- I measured voltages and began to scope out some signals.
- While using the scope, after several minutes, I heard a beep. The board would now boot. Standby light would go off. One beep followed by two beeps. Nothing on the display though. This state was reproducible at the time.
- Measured backlight voltage at 5V, not the expected 24V, while unit was on.
- Used an external bench PSU to provide 24V to the display backlight. The display turned on and showed the calibration message.
- Removed IC9, L1, ZD1, and D2. Ordered replacements.
- When replacements arrived, I installed them.
- The board will not boot. Standby light stays on. No beeps.
- I can still successfully flash the board using dfu-util.

Notes:

- I've examined every component under magnification for possible bad joints or solder bridges.
- I've manually reflowed every joint on the board, and carefully cleaned the board with flux remover.
- I've measured the resistance of every resistor on the board in-circuit.
- I can measure some proper voltages on the MCU board, including 3.3V in many places, 5V near IC9, and 12V on the backplane connector.
- I can scope a 39.7MHz clock signal on pins 1, 25, and 38 of IC14, as well as pins 35 and 41 of IC3.
- I can scope a 25 MHz clock signal on the lead of Y1. However, this clock signal cuts out repeatedly for a short period once every few seconds.
- There appears to be proper continuity from the top of IC3 pin 122 to the nearby via that I connected it to using a tiny wire. Neither neighboring pin (121 or 123) measures continuity with pin 122.

A large photo with the top and bottom of the board is attached here.

Any further troubleshooting advice would be greatly appreciated!

Dan

[prasimix]

- Used an external bench PSU to provide 24V to the display backlight. The display turned on and showed the calibration message.

Can you check what you have on Pin 4 of IC9? I see no reason why the backlight boost wouldn't work if the components are correct and well soldered?
When you got the image on the display with the application of external power supply, did you manage to do the calibration?

[loglow]

Can you check what you have on Pin 4 of IC9? I see no reason why the backlight boost wouldn't work if the components are correct and well soldered?

On IC9:

- P1 = 5V
- P2 = 0V
- P3 = 0V
- P4 = 0V
- P5 = 5V

See close-up photo attached of these components.

When you got the image on the display with the application of external power supply, did you manage to do the calibration?

I was using both hands to hold the probes powering the backlight in place, so I wasn't able to interact with the screen.

Just to clarify, the board does not presently beep at power-up and the standby light does not go off, so I wouldn't expect to see anything on the screen even if the backlight was powered.

[loglow]

FYI, my measurements taken at X2 from the bottom of the board:

   ~0V   2  1   ~0V
  +12V   4  3   +12V
   +5V   6  5   +5V
   ~0V   8  7   ~0V
   ~0V  10  9   ~0V
   ~0V  12  11  ~0V
 +3.3V  14  13  +3.3V
 +3.3V  16  15  +3.3V

[prasimix]

On IC9:

- P1 = 5V
- P2 = 0V
- P3 = 0V
- P4 = 0V
- P5 = 5V

OK, check why you don't have a signal on pin 4 of IC9: maybe the PCB trace is broken, maybe it's poorly soldered because without that signal you can't have a functional backlight. When you manage to fix it, calibrate the TFT display and see what happens next.

[loglow]

OK, check why you don't have a signal on pin 4 of IC9: maybe the PCB trace is broken, maybe it's poorly soldered because without that signal you can't have a functional backlight. When you manage to fix it, calibrate the TFT display and see what happens next.

Thank you. Reading the TPS61169 datasheet, I see that the boost driver is inactive if pin 4 (CTRL) stays low. If I apply a consistent 5V to pin 4, the display backlight does activate, so I believe that neither the display nor IC9 are the real problem. I've attached a compressed video (backlight.mov.zip) showing the behavior when power is switched on. Please note that in this video IC9 pin 4 is being deliberately pulled to 5V via a jumper wire (which I've since removed).

I have also measured proper continuity between IC9 pin 4 and IC3 pin 88.

Note that the pulsing of the display is consistent with the repeating dropout of the 25MHz clock. I haven't checked if these two behaviors are synchronized, but I can if needed. The timing of the repetitions is at least similar.

[loglow]

Update. The MCU board is working now!

The problem: I had installed component Y2 backwards.

The board marking for this part isn't especially clear—just a slightly thicker white line on one side—and the chip marking is worse—just a slightly angled facet along one edge of the package. Combine that with the fact that many crystals work in both orientations, and I missed this; my mistake. In its correct orientation, the text printed on the chip needs to be upside-down relative to the text printed on the PCB.

Now I'll continue setting up the device. Thanks again for your previous help!

[loglow]

Next problem:

I'm trying to initialize the modules. I have "Module Initialization.py" and "Module Initialization.res" in the Scripts folder of the SD card. When I go to run the script, I get an error message that says "Uncaught script exception!"

In the log, it says:

2024-08-23 18:49:18 INFO Script started: Module Initialization.py
2024-08-23 18:49:19 DEBUG **ERROR [08-23-24 06:49:19 PM]: -321,"Out of memory"
2024-08-23 18:49:19 DEBUG Traceback (most recent call last):
2024-08-23 18:49:19 DEBUG   File "<stdin>", line 120, in <module>
2024-08-23 18:49:19 DEBUG ValueError: SCPI error -321, "Out of memory"
2024-08-23 18:49:19 INFO Script ended: Module Initialization.py

I tried searching for this situation/error but didn't come up with anything.

How should I proceed?

Thanks,
Dan

[prasimix]

In that case, you either have an old version of the firmware or the script. You can also use EEZ Studio to upgrade the firmware, as well as to upgrade the script.

[loglow]

In that case, you either have an old version of the firmware or the script. You can also use EEZ Studio to upgrade the firmware, as well as to upgrade the script.

Thanks, the MCU firmware was the latest, but the script must have been outdated. I downloaded it from github after following the link in the assembly instructions. I was able to successfully use EEZ Studio to update the script and initialize the modules. I was also able to flash the firmware onto the DCM220 module.

I have a few followup questions for you:

1. One DCP405 module throws the following error on boot:

2024-08-25 16:34:27 DEBUG Ch1 DAC test, U_set failure: expected=20, got=-0.85, abs diff=-20.85
2024-08-25 16:34:27 DEBUG Ch1 DAC test, I_set failure: expected=2.5, got=-0.109, abs diff=-2.609
2024-08-25 16:34:27 ERROR CH1 DAC test failed

2. The other DCP405 module throws a different error on boot:

2024-08-25 16:35:41 DEBUG Ch1 IO expander reg check failure: reg=4, expected=32, got=0
2024-08-25 16:35:41 ERROR CH1 IOEXP test failed
2024-08-25 16:35:41 ERROR CH1 ADC test failed

If you have any immediate thoughts about these errors, let me know. Otherwise, I'll scrutinize both DCP405 boards carefully and proceed with troubleshooting them.

I was able to voltage calibrate the DCM220 module and it appears to work. I'll try current calibrating it tomorrow. In the meantime I had a few questions for you about the behavior of this module:

3. On one (and only one) occasion, the DCM220 module threw a "CRC check" error in a popup message. Strangely, this error did not appear in the log. However, there are several examples of messages like this in the log:

2024-08-25 16:37:08 DEBUG Slot 3 CRC 1
2024-08-25 16:37:08 DEBUG Slot 3 CRC 2

After the error, the module was unusable (displaying "Error" in red) until the BB3 was rebooted. After rebooting, it worked fine and has continued to work fine. What do these debug log entries signify, and should I be concerned about them? Also, is the isolated CRC error something I should be worried about?

4. The 2nd channel of the DCM220 seems to oscillate a bit at certain voltages. For example, when set to 5V, the output appears to slowly cycle between 4.98V and 5.03V. This is with no load attached; I will test this under load tomorrow. Is this behavior within spec or does it indicate a problem? Ch1 sometimes cycles back and forth between intervals (eg. 4.98V and 4.99V) but seemingly less-so than Ch2.

5. Both DCM220 channels appear to not be able to output anything below about 1.5V. For example, when set to 1V, Ch1 outputs 1.58V and Ch2 outputs 1.55V. This is with no load attached, but after calibration was performed. Is this expected behavior? I can also test this behavior under load tomorrow.

Thanks so much for all of your help so far.

Best,
Dan

[prasimix]

Check on the first DCM405 module everything related to the DAC as well as the ADC because the selftest requires that both are functional. On the other, there is obviously something wrong with the communication or IOEXP.

The CRC error indicates that there is a possible communication problem with the slave MCU that is on the DCM220. If it keeps appearing, it should be investigated whether the digital isolator and the MCU are well mounted.

DCM220/224 cannot regulate below 1.5 V so it is not a bug.

[loglow]

Check on the first DCM405 module everything related to the DAC as well as the ADC because the selftest requires that both are functional. On the other, there is obviously something wrong with the communication or IOEXP.

Thank you. After some rework and inspection, both modules now pass their initial self-tests ("OK"), but they still have some problems. One DCM405 shows constant voltage of 39.14V in red on the screen and it cannot be enabled. The other module displays a temperature "failure" on boot (after self-tests OK) and then trips OVP after about 1 minute no matter what the voltage actually is (or is set to).

I plan to reinspect both boards carefully and probably manually reflow all solder joints on them. I tried using a new kind of solder paste (Chip Quik TS391LT) for this project and I'm probably never going to use it again ... gonna go back to my usual SMD291AX.

The DCM220 hasn't shown any additional CRC errors, so perhaps that error was a one-off. That module seems to be fine otherwise

[loglow]

Hi, I had a chance to keep working on this. I reflowed and inspected all solder joints on both boards, so I suspect one or more component failures are causing these issues:

- The first DCP405 module passes initialization OK. It still shows a flashing red 39.14V below OFF and cannot be activated.

- The second DCP405 module also passes initialization OK. I fixed the temp error by replacing the temp sensor IC and now it reads correctly. The module can be activated, but its output voltage does not change when its voltage setting is changed; it stays at around 100mV. If set to anything above about 1-2V, a hardware OVP error is triggered. If hardware OVP is disabled, you can set it to any voltage but the output voltage remains unchanged.

Any thoughts?

I also have a separate question for you about the DCM220:

- I successfully calibrated both channels. Channel 2 behaves as expected. Channel one behaves as expected until it's set to anything above 19.92V, at which point the output voltage begins scaling to a maximum of 20.15V when the setting is at 20V. Strangely, this behavior is the same no matter what value the 20V calibration point is set to. Is this behavior within spec or correctable?

[prasimix]

The DCP405 OVP works as expected: it monitors the difference between the set and the output voltage and trip if that difference is too large. Since the voltage regulation is obviously not working, the higher the set voltage, the faster the OVP will react. Check all the components belonging to the voltage regulation as well as the output enable circuit.

I can't say anything about the DCM220 at this point.