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.