FIXED - Anyone able to help getting this code to work on my load?

[microplayer]

Hello everybody. Although reference to this code is found on many places on the internet there a no hints about successful implementation of the code.
Since I kinda bricked my load (it is just beeping, but no display active anymore) when using the steps described her, I am looking for any hints on what could have been gone wrong and even better: How to get it back working again.
As of today I found no mentioning of incompatibilities with newer devices. Mine is from end of august 2019. Any help is highly appreciated - please use <...> to reach me.
Thank you, microplayer

EDIT: Email address removed from all comments.

[herm]

Does your load look identical to the one in the "component locations" image?

Could you please describe what exactly you did? Compile the software, flash it, clear eeprom?

[herm]

Do you have anything connected to the input? Sometimes voltage fluctuations on an open input are detected as an reverse polarity on the input and the device goes to error mode. If the beep you hear after power on is a fast sequence of short beeps this might be what happens. You could try shorting the input pins together.

[microplayer]

Guten Abend, Herr Kraus!   Vielen Dank, dass Sie sich die Mühe machen, mein Problem anzuhören!   Die beiden Eingangsanschlüsse habe ich gerade mal gebrückt - jetzt höre ich nur noch ein sehr kurzes Piepsen. Wenn ich mich recht an den Quellcode erinnere, könnte das der kurze Beep am Beginn der Initialisierung sein:       beeper_on();     delay10ms(10);     beeper_off();   Leider bleiben beide Displays aus. Kein weiteres Piepsen. Keine Reaktion auf den Encoder inkl. Taster und den Start-Taster.   Das Layout meines Gerätes (Aliexpress vom August 2019) ist identisch mit dem Foto auf Github. Die Werte von R,C usw. kann ich im Detail nicht erkennen. Aber R und C sind an den richtigen Stellen, ICs und Transistoren auch.   Da ich mir das Riskio bewußt war, habe ich brav alles in der Reihenfolge gemäß Anleitung gemacht. SDCC habe ich in der aktuellen 4.0 Version auf meinem Mac per Homebrew installiert. Die STM-Tools habe ich anhand der Einträge im Makefile gefunden und ebenfalls in der aktuellen Version per Homebrew? installiert. Als Programmer habe ich einen kostenfreien Nachbau des ST-Linkv2 zur Hand. Auf der STM8 Webseite ist ein nicht zerstörerischer Testzugriff auf den STM abgedruckt, den ich erfolgreich durchgeführt hatte. Daher halte ich die Software auf dem Mac, die USB Verbindung zum ST-Link und weiter zum STM8 selbst für i.O.   Dann gemäß Github die Schritte durchgeführt make unlock make flash make clear_eeprom   Die Make Aufrufe sahen alle OK aus. Ich habe auch keinerlei Änderungen am Makefile vorgenommen. Aber die Load startete nicht. Ja nachdem kam von Anfang an (langsameres, 500ms?) Dauerpiepsen in Intervallen, manchmal erst nach Betätigen von Encoder-Taster oder Start-Taster. Das Display war nie wieder an.   Was mich etwas verwundert hat: Das Binary electronic_load.ihx ist laut Mac 22,6 kB groß Das stm8flash Utility sprach aber immer davon, 9220 Bytes ab #8000 zu schreiben... Da bin ich mir nicht sicher, ob das korrekt ist.    Dann kam mir die Zeile mit make clear_eeprom am Ende merkwürdig vor... Hätte ich eher am Anfang vermutet. Daher alles nochmal in geänderter Reihenfolge:   make unlock (vermutlich ohnehin unnötig)   make clear_eeprom   make flash   Hat aber leider nichts gebracht. Die Last reagierte aber immer immer noch auf den Programmer.   Deshalb habe ich noch Hoffnung auf Wiederbelebung.   Sollte ich nochmal flashen mit gesetzter Drahtbrücke am Eingang? Wenn ja, in welcher Reihenfolge sollten die Make Aufrufe kommen? Eigentlich sollte doch "make flash" reichen? Wir haben doch schon alles zurückgesetzt, oder?     Nochmal Dankeschön aus Leverkusen für Ihre Hilfe!   Roger Zink

[microplayer]

Die CPU ist in meinem Exeplar übrigens auch identisch mit dem Eintrag im Makefile: PROCESSOR=STM8S005K6... Roger Zink

[herm]

Note to everybody reading this on Github: I will add an english summary after this issue is solved.

Hallo!

Das es nur noch einen Piepser am Anfang gibt klingt schon mal besser. "clear_eeprom" nach dem "flash" ist schon richtig. Führt man es andersrum aus schreibt die Originalfirmware evtl. wieder ins EEPROM bevor man die neue Firmware draufgespielt hat. Sollte aber auch kein Problem sein, weil dann die Checksumme mit hoher Wahrscheinlichkeit nicht stimmt und das EEPROM automatisch neu initialisiert wird.

Auch die Größe vom Hex-File stimmt. Im Hexfile steht das Programm ja Hexadezimal codiert drin während der ST-Link das binäre Programm schreibt. Deshalb ist das Hexfile immer größer.

Es scheint also nur ein Problem mit der Ansteuerung vom Display zu sein. Ich weiß nicht ob die Chinesen da was geändert haben. Bei mir sind auf der Rückseite 2x TM1650 drauf. An Pin 1 und 2 sollte 0V, an Pin 3 5V und an den Pins 4-6 knapp unter 5V anliegen. Gemessen jeweils gegen den GND Pin auf der ST-Link-Anschluss. Wenn du ein Oszi oder einen Logicanalyzer hast müsstest du auf den Pins 4-6 die Datenübertragung sehen. Vielleicht ist da ja was geändert oder beim Einlöten des Steckers kaputt gegangen.

Viele Grüße

Hermann

[microplayer]

Hallo Hermann, ich schaue es mir morgen (Abend) mal an. Oszi habe ich. Aber was mir aktuell fehlt, ist das emulierte "Knacken" des Encoders beim Drehen wie bei der Original-Firmware. Das vermisse ich. Daher befürchte ich, dass das Problem nicht nur in der Displayansteuerung liegt. Vor dem Flashen war das Gerät noch voll einsatzfähig. Ich hatte es für Tests als Last benutzt. Gute Nacht und eine prima Woche!   Viele Grüße  Roger 

[microplayer]

Let´s switch back to english...

@hermann: Could you please delete my email address from the up-level paragraph? Thank you!

Hermann, you suggested to do some measurements at the pins of the TM1650 LED display/keyboard drivers on the piggy-back display board.
This seems to point to a distinct change in board layout compared to your/the original device.
On my piggy-back display board they placed some IC = maybe those TM1650 right underneath each 7-segment LED block. They hardly fit underneath. No way to do some measurements without de-soldering the LEDs. And of course, no vias from those IC´s to the lower layer...

1. Could you please tell me, where the pins from those TM1650´s end up on the 4-segment and 3-segment LEDs? I do have a reverse engineered schematic by Luca Zimmermann from 11.01.18. Do you know if I should use it as a reference?
2. Are there pins available on my "STM8 S005K6T6C 990MJ VG MYS 901" CPU or elsewhere on the mainboard, that could serve as a definitive indicator that your code is actually running? So that we can be sure that flashing was successful and your code is executed.

B.t.w. here´s the output while writing to flash again today - with input pins shorted:
make clear_eeprom stm8flash -c stlinkv2 -p STM8S005K6 -s eeprom -w empty_eeprom
Determine EEPROM area
Due to its file extension (or lack thereof), "empty_eeprom" is considered as RAW BINARY format!
128 bytes at 0x4000... OK
Bytes written: 128
make flash stm8flash -c stlinkv2 -p STM8S005K6 -w build/electronic_load.ihx
Determine FLASH area
Due to its file extension (or lack thereof), "build/electronic_load.ihx" is considered as INTEL HEX format!
9220 bytes at 0x8000... OK
Bytes written: 9220

Again, just one short beep. No display, no action on encoder or run button.

Cheers, Roger

[herm]

Hello Roger,

I just added some images of the display (folder: images).
The schematic by Zimmermann is mostly correct. It is part of this repository (directory: hardware). I added a few minor corrections at the end of the README.

At the left there is a connector which contains UART pins. It is located at the left edge of the main PCB.

Pins:

• G: GND
• R: RXD
• T: TXD

On TXD you should see a continuous output of the current state at 115200 baud. If you don't see anything there you might want to throw in a few printf()s in main() to see how far the initialization goes before something stops working.

[herm]

Do you power the device with a 12V supply. I just tried connecting the ST-Link only and got exactly the same behavior you saw. Beeping, but no display.

[microplayer]

The device is powered by a little 12V 1A power supply. I did the programming several times - some only with power from ST-Link, some with the external supply hooked on in addition. However, I always removed ST-Link when I tried to bring the device online.
@herm: Talking power supply - are you referring to the time while programming it or while actually running it and testing it?

@herm: Unfortunately I´m currently a bit busy in my job. I think I´ll find some time next weekend to follow your valuable guidelines. If chinese and german post are still in business I hope to receive another ZPB30 device to be able to compare those two. Thank you very much so far!
"I'll be back..."

[microplayer]

First things first: My ZPB30 is built with ET6226 "LED drive control circuit with a keyboard scanning interface". I desoldered the lower LED display block which uncovered the driver IC. Let´s assume the other display is using the same IC (Murphy, stay away!!!).
Some details on this IC can be found here: [http://www.etek.com.cn/en/product.asp?ID=174].
I also uploaded some fotos.

Although it seems to be pin-compatible with the original TM1650 initially used here, I might experience some timing issues or other nasty stuff. This would explain inability to display information and missing reactions on pushbutton input, at least to my understanding.
My analog oscilloscope shows flickering 5V TTL level signals on SDA and CLK of the ET6226. Since it is no DSO I am unable to tell if those signals make sense from a protocol standpoint.

As a prove, serial output collected from the left-hand side RS232 connectors is looking good:
"0 T 225 Vi 11898 Vl 16 Vs 0 I 1700 mWs 0 mAs 34
0 T 225 Vi 11900 Vl 18 Vs 0 I 1700 mWs 0 mAs 34
0 T 225 Vi 11899 Vl 17 Vs 0 I 1700 mWs 0 mAs 34"

For better comparison I listed the pinout of both chips in a spreadsheet - hardcopy attached.
There are some other projects here on GitHub which reference the ET6226.
I came across this one which states that ET6226 and TM1650 should be compatible.
[https://github.com/TG9541/stm8ef/issues/248]

@hermann: Could you please have a look at the TM1650 code if there are some TM1650 specifics in the code that would prevent using a ET6226 - if it is in fact compatible? Although pin layout looks the same, there might be some discrepancies between registers and return values.

Roger

[microplayer]

If helpful to anybody I have now a no-name 8-channel Logic Analyzer (bought on AZ-Delivery) connected to SCL and SDA on the 10-pin connector to the display. There is something happening on those lines which is displayed by open-source PulseView using the I2C protocol decoder. Unfortunately I can´t derive any information out of it because I don´t have any experience here. Maybe someone out there is able to "remote control" me to fetch helpful signal diagrams.

[herm]

As far as I understand the Chinese datasheets the TM1650 and the ET6226 should be fully compatible. It would help me debug the issue if you could attach the logic analyzer to pin 2 and 3 of the ET6226 and record a trace while rotating the encoder. You can save the raw data using pulse view and send me the file.

Does pressing the "Run" button change the serial output?

As I have added remote control via the serial port now you should be able to use your load again (but without the display obviously).

[microplayer]

Ok, I will try to fetch the data. One question, however: Should I really turn the encoder while traceing SDA and CLK? The Encoder ist directly connected to the CPU according to the hardware schematics, not the ET6226 display drivers. I followed these traces on the display board going into the 10-pin connector. If I understand correctly, turning the encoder should therefore not create any telegrams visible on SDA/CLK.

[herm]

It will create telegrams because turning the encoder changes the text on the display. There is a continuous stream of data to the top display (because it blinks) but the bottom one (which you desoldered) is only updated when rotating the encoder.

[microplayer]

Good morning!
Hopefully I managed to get some useful LA outputs. Scans with 1 MHz sampling rate didn´t make any sense to my (weak) understand of I2C in the first place. So I thought I should better shorten the lines as far as possible to prevent interferences. See foto of my current lab setup if it makes sense to you.
In a later step I raised sampling frequency to 12 MHz while turning the encoder - and then things seem to "look better". Especially on the CLK signal. For your reference, SDA2 is connected to pin 4, which is also connected to the CPU according to the schematics. But doesn´t move at all in my case.
Please see attached file "ZPB mit Drehung des Encoder bei 10MSps und 10MHz.sr.zip".
ZPB mit Drehung des Encoder bei 10MSps und 10MHz.sr.zip

[microplayer]

Short update: I checked the actual pins of the lower 7-Segment display SP420361N by ARKLED with my analogue oscilloscope. Fotos were taken with my old Finepix camera, which was "slow" enough to catch the whole signal train on the cathode tube.
The much faster iPhone only showed parts of the signal train. Funny problem, I think I have to invest in a modern DSO with hardcopy option...
Fotos are attached - all were taken using 2ms time/div, variable hold-off time to catch the signal train and 0.2 volts/div behind a x10 probe = which is equivalent to 2V/div on the screen.
Finally I also checked if my 7-segment display worked at all - yes, it does! Bright red segments.

In short: The ET6226 is/are switching the common cathode inputs of the display, BUT the ET6226 keeps ALL segment A-G+DP inputs to LOW constantly. Therefore the display stays dark.
I could imagine that issues during I2C communication with those ET6226 or by internal incompatibilities in comparison with the original TM1650 are a possible cause.

Please check fotos yourself. One other thing, the common cathode inputs of Digit-2 and Digit-3 (pin 8 and 9) are set to low TWICE shortly after another. This is not case with Digit-1 (pin 12). Any comments and suggestions are very much appreciated.

[microplayer]

Just being curious:
The CPU frequency in config.h is defined like:
//F_xxx is in Hz
#define F_CPU 16000000L
#define F_SYSTICK 100

Now, the quartz on my board is a 12 MHz one.
A physical difference between our two boards, a typo, a software trick? Or is the quartz frequency no issue at all? Even not for I2C?

Cheers, Roger

[microplayer]

Almost forgot to tell you:
The serial output is working well.
If I blindfolded turn and click the encoder and/or the run button I do see changes in different columns of the serial output. The values stay put until I turn and change some parameters again.
So the firmware in general seems to be working .
Display output seems do be our main issue here.
I played again with Pulseview and the Logic Analyzer. I do not have too much expertise here, but the output especially for CLK looks very much disrupted = not isochrone over the course of one read or write. Even worse over the course of 3-4 R/W accesses. The widespread distances in time between consecutive CLK pulses don´t look anything in all the documented I2C examples on many I2C Youtube videos I´ve seen.
The 100 Hz intervall to R/W access to the ET6226 seems to be stable according to Pulseview output. But those very much faster/shorter CLK pulses are not following a rigid pattern in time.
Please remember, I´m a Pulseview novice. I can´t exclude one/many systematic errors in the LA setup of my little lab here.

[herm]

While I2C does not depend on precise timing I have identified a potential problem: The current code outputs the I2C signal as fast as it can. This is fine with the TM1650 but might be too fast for the ET6226. It is hard to get accurate timings from the logic analyzer traces because the time resolution is too low but it look like we are at least very close to the limits in the datasheet. I will try to build a version which is a bit slower tomorrow and then you can test it.

[herm]

Sorry, I was busy the last few days. I hope to get the software ready soon.

[microplayer]

Hello Herm,
in the meantime I received a spare electronic load to work on my other projects.
Would it help you developing a ET6226-capable software version if I would send my initial or "problematic" device to you?
Cheers

[microplayer]

Ups!

[herm]

Hello!

Sorry, I completly forgot about this problem. I made the new software now.

Version 1 (branch: ET6226_1)

This version does the following things in a continous loop:

• Initialize the display
• Count from 0 to 9 on all digits
• Emit a short beep to prove it is working

You should measure roughly these voltages on the display connector pins:

• Pin 1: 0V
• Pin 2: 0V
• Pin 3: 5V
• Pin 4: 4.2V
• Pin 5: 4.2V
• Pin 6: 3.7V

Version 2 (branch: ET6226_2)

This version is based on version 1, but activly drives high and low levels on the I2C pins. Usually you use open collector outputs with I2C but then you need pull-up resistors. A typical value is 2k2. However this board does not have external pull-ups but relies on the internal pull-ups which are 30k-80k. This might be too weak. I noticed that when I touch the SDA pins with my probes sometimes the update stopped. So this might be a real problem. Both display drivers seem to have internal pullups as well, but I'm not completly sure if I understand the chinese datasheet correctly.

Version 3 (branch: ET6226_3)

This version is based on version 3 and adds a lot of delay in the I2C code. This makes it very slow but should help a lot if there are any timing problems. It is still counting from 0 to 9 but each digit takes about 10s. So you should only hear a beep every 2 minutes.

Could you please try if one of these versions work on your hardware? If the don't work it would be very helpful if you could send me some logic analyzer traces from your working hardware. The should start right after power on so I can see any initialization that might me missing in the current code. Thanks!

[microplayer]

Hermann, thank you so much for your work!
These days I´m busy with different projects, I´m afraid.
Feedback will be arriving next weekend I hope.

Until then, Roger

[microplayer]

I think we made some important progress :-)

In short:

1. The PCB layout of my TWO ZPB devices seem to have changed compared to the initial one used by Herm and his co-writers!
 There are now TWO DISTINCT SCL1 and SCL2 clock lines which go from the STM8 controller separately to the upper and the lower ET6226 driver. They are connected via pins 4 and 5 on the 10-pin connector between mainboard and piggyback. In contrast, the „schematic.pdf“ in the „hardware“ subdirectory on GitHub shows two distinct SDA1 and SDA2 lines, which are connected to the respective ET6226-upper and -lower. In my two cases, both ET6226 share a common SDA on pin 6, with a 5k1 resistor as common pull-up onboard. As a side note, there are no external pull-ups to SCL1 or SCL2.
   

2. I could prove this change by two photos I took when running the TM1650 demo. See details below.
On the photo with the upper display lit you’ll notice that the white cable with SCL from the Arduino was connected to pin 4 - next to the red cable which carried Vcc.
The second photo shows the white SCL cable on pin 5 to the left of the green SDA cable - ond the bottom display lit up.

To my understanding, we might need two main changes to the existing software in order to run on newer devices just like mine:

1. Optimise/adjust the timing for the two SCL and SDA lines according to the TM1650 library and - possibly more important - the foundational „Wire.h“ Arduino standard library. Reason being that the three test branches didn´t show any activity on my two piggybacks. See below for details.
Please check this website, which states that TM1650 - the original driver - does not use the real I2C protocol, but just a stripped down version of it.


[https://os.mbed.com/users/wim/code/TM1650/file/4430a1559b4f/TM1650.cpp/]„TM1650 uses a Serial bus that looks like I2C, but really is not.It has Start and Stop conditions like I2C and an Ack pulse, but instead of slaveaddresses and a RW bit it just transmits commands and data.“


2. Implement two separate SCL clock routines for ET6226 upper and lower using two separate STM8 outputs. In fact, turning the existing SDA2 output into a SCL2 output. This one especially might require a lot of changes inside the software.

3. Find a smart way to offer both variations of the code for easy digestion by unexperienced users. Enhance the schematics and the READMEs.

There are still a lot of ZPB30A1 offers on ali* and bang* available. There should be hundreds or maybe thousands of people looking for a better firmware.

@herm: Please continue your great work on this little device.

Regards, Roger

—————

Addendum:
If you are interested how I came to this conclusion just go on reading:

First step was to compile and test run the three branches ET6226_1 to ET6226_3 against the problematic device. Not a single flash on the LED segments. At least the beeps were noticeable according to the loop intervals. Rechecked it with the piggyback PCB from my new load which arrived in march.
 Unfortunately no reaction either.
By the way, the newer one now has a version print on the piggyback - „ZPB30A1P V2.9“.
See the photo attached.

In step two I used one of my Arduino Unos and compiled and ran „I2C Scanner“ by Wolfgang Ewald from [https://wolles-elektronikkiste.de/i2c-scanner] .
The tool was not able to detect any valid I2C component on the SDA/SCL links.
No change after I put a connector with 5k1 ohm and even 2k2 resistors on top of the piggyboard. The information about a "stripped down version of I2C" being used does explain this.

Then came step three where I compiled and ran the „TM1650_example01.ino“ which is part of the Arduino standard library „TM1650“ repository by Anatoli Arkhipenko on GitHub
[https://github.com/arkhipenko/TM1650]

To my surprise I saw all the output on the bottom 3-segment display on the board!!!
In fact, I saw the blinking on the remaining 3mm LEDs only, since the 7-segment display block was already unsoldered :-)
No reaction on the upper one, however.

This was reason enough to also remove the 4-digit LED block on the piggyback. It was the only way to find out why the lower display worked, but not the upper one.
See photos attached.

Using the continuity beeper of my multimeter it turned out that the manufacturer of my two devices might have changed from a „2 separate SDA lines“ to a new „2 separate SCL lines“ approach in order to address two ET6226 on the same bus. Unfortunately, ET6226 as well as the original TM1650 are not fully I2C compliant, but use only a trimmed down protocol version of it. According to documentation on the web - see above - you cannot run two ET6226 on the same I2C bus, because they do not support distinguishable addresses. Hence the workaround with two SCL lines and one common SDA line.
Or vice versa, as in Herm´s device(@herm: ?).

[microplayer]

Hello, Herrmann! Did you have the opportunity to take a look at my findings above?
Cheers, Roger

[microplayer]

Herrmann,
please check my findings above. They really changed the way how they addressed the ET6226 - from a „2 separate SDA lines“ to a new „2 separate SCL lines“ approach.
I will now close the case and momentarily re-open it to catch your interest. It worked last time :-)
Thank you in advance!

[microplayer]

Here we are again...

[herm]

Sorry, I'm currently busy with other stuff but this issue is on my TODO list.

[microplayer]

Nice to hear from you, Herrmann :-)
And perfectly ok.
One thing:
I could send you my "problematic" electronic load to speed up your development, if you like.
No big deal since I own a second one.

[skygunner]

hi, does this code suit the 110W ZPB30A1 as well or it needs to be adjusted?

Ok, the 110W is coded ZPB30A2. not supported.
The ZPB30A1 on sale is v2.9 which is not supported.
The seller is rolling out v3.0

[herm]

Sorry for the late reply. The 110W version is not supported at the moment. If only the power rating is changed you probably can make it work by changing a few constants in config.h. You could start by comparing the schematics. If they match or almost match you can probably use this software.

@microplayer: I still didn't find time to work on this issue. Sending me the device won't speed it up because I currently have quite a lot of other (much more important) things to do. Sorry.

[unemployable]

Hi,
I also have the newer hardware (V2.9) and wanted to try out this project.

Based on microplayer's detective work, I modified the code to try and get around the display pin changes.
Was pleasantly surprised when it worked...

Attached is a patch with the minor changes (config.h, electronic_load.c & tm1650.c).

ZPB30A1_Firmware_v2_9.patch.txt

[microplayer]

Hello unemployable,

this is a really good message!
Can´t wait to test it out - unfortunately my. time is limited now.
I´ll give it a try as soon as possible.
Thank you!

@ALL: Anyone out there who can test it now?

Cheers,

microplayer

[microplayer]

Hi everybody,
today I can confirm that the suggested patches by "unemployable" also did fix the issue on my electronic load.
Wonderful!

Since I am new to the patch workflow myself I´ll add some comments about the patch process:
Make sure to use the commit 96da989 from 30th of march in herm´s Github repository as your original code base.
Before you run the Linux patch command try to understand the directory structure "old" vs. "new" as used by "unemployable" and how you should arrange directories old/new on your PC accordingly.
You´ll get an understanding by looking at the three diff lines in unemployable´s "ZPB30A1_Firmware_v2_9.patch.txt" file.
Check the "-pX" option of the patch command to shorten pathes so the remaining structure is common between your installation and the one used by "unemployable".
Then connect your STLink programmer and run the "make flash" command in the "new" directory to flash the new code to the load. You might need to create a "build" directory under "software" manually - if the SDDC throws error messages pointing in that direction.
That´s it.

Many thanks to herm for the initial code and unemployable for the essential changes to address the changes in the hardware layout of newer loads.
Kind regards,
microplayer

[herm]

Thank you @unemployable for providing the code.
Thank you @microplayer for testing.

I will test if this version also works on the old hardware version and merge the code afterwards. I'm leaving this issue open till the code is merged.

[microplayer]

Herm,
while reviewing the changes done by @unemployable please double check the way CMD errors might appear on the display. I moved the components into an 80s style ELV housing. When I ran tests using "Constant Resistance" mode to check power dissipation I experienced two CMD errors in a row. Power supply should deliver 12V and around 4,5 A of current, resistance was set to 2,7 Ohms. When pressing the START button, the load works for around 2 minutes as designed when suddenly CMD was displayed. Load was then switched off. After 2 minutes or so, same procedure was restarted. Same CMD error outcome after around 2 minutes. The 3rd try ran finally through for the next 15 minutes or so when I finally switched it off by hand. From a temperature perspective everything was fine. But the CMD issues leave me skeptical.