MK-312 BT der ET312 Nachbau

[Bombenleger802]

Guten Abend zusammen,

nach einer längeren Bastelpause bin ich von den ganzen Spannenden Sachen auch mal zu etwas ruhigerem gewechselt. Low Voltage

Es geht um das berühmte MK312. Den Anwendugszweck dieses Gerätes will ich jetzt nicht genauer erkäutern, ich denke viele wissen darüber Bescheid.

Mein Problem ist nun jedoch, dass ich von dem Mikrocotroller zeug bis jetzt noch recht wenig Ahnung habe und jetzt vor dem 2. nicht funktionierendem Board stehe. Es ist nicht der Fehler 20, sondern einfach nur eine Reihe an weißer Kästchen in der ersten Reihe des LCD Pannels. Wie gesagt, um Probleme auf dem PCB aus zu schließen habe ich das Teil nochmal neu aufgebaut, jedoch ohne Erfolg.

Kennt jemand von euch vielleicht den Fehler und könnte mir hier weiter helfen? Das Forum, welches eigentlich für die Betreuung des Projets zuständig ist, hat leider seit Anfang 2021 dicht, bzw. macht ein Backup

Hier noch ein GitHub Link zu dem Projekt. Vielleicht findet ja noch jemand das Teil ganz interessant.

Schönen Abend noch.

Liebe Grüße,
Luca

[Alexander470815]

Eine Reihe weißer Kästchen bedeutet dass das Display nicht initialisiert wurde.
Das ist das was der HD44780 von sich aus macht.

Deutet also darauf hin das der Controller nicht läuft sofern alle Sachen korrekt angeschlossen sind.
Du kannst ja mal auf den Anschlüssen die zum Display gehen mit dem Oszilloskop rumstochern und gucken ob sich etwas tut.

Den Programmcode hast du von irgendwo heruntergeladen?
Wie programmiert?
Braucht das vielleicht eine andere Clock Quelle als am Microcontroller per Fuse Bits eingestellt ist?

Wenn du das von Github hast: https://github.com/CrashOverride85/mk312-bt

Code: Alles auswählen

We are using an external 8mhz crystal instead of the internal RC oscillator that the original uses. We need to set the fuses to enable this.
LOW FUSE: 0xFF
HIGH FUSE: 0xDC

[Bombenleger802]

Hallo Alexander,
ja ich vermute auch, dass der Controller gar nicht erst aufstartet und das Display initialisiert. Leider habe ich von der Software auch nur die .bin files, also keinen richtigen Quellcode. (Genau, dass ist der Link, ich habe es oben vergessen ein zu fügen) Somit kann ich auch nicht genau sagen, wie der startup abläuft und wo der Controller möglicherweise hängt.

Den Programmcode hast du von irgendwo heruntergeladen?
Wie programmiert?
Braucht das vielleicht eine andere Clock Quelle als am Microcontroller per Fuse Bits eingestellt ist?

Wenn du das von Github hast: https://github.com/CrashOverride85/mk312-bt

Code: Alles auswählen

We are using an external 8mhz crystal instead of the internal RC oscillator that the original uses. We need to set the fuses to enable this.
LOW FUSE: 0xFF
HIGH FUSE: 0xDC

Ja genau ich habe die Firmware da runtergeladen und mit einem Arduino Uno und avrdude geflasht. Die Sicherungen habe ich ebenfalls so gesetzt wie es in der readme empfohlen wird. Der externe crystal ist ebenfalls verbaut.
Eigentlich sollte das mit dem oscillator somit passen, aber ich bin da für Vorschläge offen.

Ich habe nach diesem Muster geflasht:

Code: Alles auswählen

Test Connection
avrdude -c avrisp -P \\.\com24 -b 19200 -p m16 -t
Set Fuses
avrdude -v -c avrisp -P \\.\com24 -b 19200 -p m16 -U lfuse:w:0xff:m -U hfuse:w:0xDC:m
Upload Firmware
avrdude -v -c avrisp -P \\.\com24 -b 19200 -p m16 -U "flash:w:312-16-Dev_BL.bin"

Das Vorgehen kommt von ihm, ebenfalls die Verdrahtung zu den controller: http://deviant-designs.co.uk/2019/08/18 ... n-arduino/

Ein paar Sachen variieren bei mir jedoch zum original Schaltplan
Ich habe als Mosfets die LU120N statt den IRL520N, diese sollten jedoch exakt gleich sein. Zudem habe ich darauf geachtet, dass ich genau die IRF9Z24 von Infinion verwende. Hier gibt es ein interssantes Thread zu einem ähnlichen Fehler.
Ich werde diese Woche bei der Arbeit mal das Board mit einem ordentlichen Oszi durchmessen und schauen was die Fets bei startup machen, vorallem war die Spannung über den 0,5Ohm Widerstand so macht. Hieraus sollte ich schließen können ob der DAC und die Konstantstromquelle richtig arbeiten.

Falls noch jemand weitere Ideeen hat gerne her damit. Grundsätzlich sollte das Projekt auch für den Bau eines Frequenzgenerators mit höherer Ausgangsspannung recht interessant sein.

Gruß,
Luca

[Bombenleger802]

Hallo zusammen,

also es gibt ein paar Neuigkeiten. Ich habe gestern mal mit dem Oszi ein paar Singale nachgemessen, dabei ist mir aufgefallen, dass Am Ausgang eigentlich rein gar kein Signal sichtbar ist. Also nicht einmal der DAC macht ein PWM Signal für den Selbstcheck.
Ich vermute also, der Start wird in der Firmware verhindert, da er gar nicht erst so weit durch läuft oder die Firmware ist gar nicht richtig installiert. Ich habe es nun aber schon wirklich zig Mal versucht diese neu drauf zu spielen.

Habt ihr Ideen? Der Quartz taktet auf jeden Fall, das konnte ich messen. Ich vermute das heißt aber noch lange nicht, dass auch die Firmware läuft oder?


Danke euch,

Gruß
Luca

[Alexander470815]

Du könntest in das Programm ein paar Befehle einbauen die mal einen Pin setzen und wieder zurücksetzen, dann kannst du ungefähr sehen wie weit der Controller im Programm kommt.
Eine alternative wäre wohl einen Atmel-ICE zu verwenden und das ganze zu debuggen.

[Thunderbolt]

Du könntest in das Programm ein paar Befehle einbauen die mal einen Pin setzen und wieder zurücksetzen, dann kannst du ungefähr sehen wie weit der Controller im Programm kommt.
Eine alternative wäre wohl einen Atmel-ICE zu verwenden und das ganze zu debuggen.

Wollte ich auch vorschlagen, aber ich glaube wenn er nur die .bin datei hat, wird das nicht so einfach

[Bombenleger802]

Guten Tag zusammen,

ich habe mal wieder schlechte Nachrichten. Heute habe ich vergeblich versucht eine andere Software auf den Atmega16A zu flashen. Laut avrdude wird diese vollständig auf den Chip geladen, jedoch habe ich bisher keine Funktion fesstellen können.

Code: Alles auswählen

 * Blink Test.c
 *
 * Created: 03.07.2021 10:33:38
 * Author : Luca
 */ 
#define F_CPU 16000000UL
#include <avr/io.h>
#include <util/delay.h>

int main()
{
   DDRB=0xFF;
    while (1) 
    {
		PORTB=0xFF;
		_delay_ms(100);
		PORTB=0x00;
		_delay_ms(100);
    }
}

Dieses Programm habe ich testweise in AVR Studio geschrieben und anschließend das .hex file auf den Atmega geladen. Eigenlich hätte die LED an dem PIN blinken sollen. Ich habe den Chip nur 5V auf Pin 10 und GND auf 11 gegeben, was ja eigenlich ausreichen sollte um zu starten.

Naja irgendwie bin ich mit meinem Latein am Ende :/

Und ja leider habe ich nur die .bin files, also kann ich nicht einmal nachschauen, wo er überhaupt hängen bleiben könnte... Alles ziemlich blöd

Gruß,
Luca

[Paul]

Dieses Programm habe ich testweise in AVR Studio geschrieben und anschließend das .hex file auf den Atmega geladen. Eigenlich hätte die LED an dem PIN blinken sollen. Ich habe den Chip nur 5V auf Pin 10 und GND auf 11 gegeben, was ja eigenlich ausreichen sollte um zu starten.

Ein RESET-Widerstand muss bitte auch sein. 10k von !RESET nach VCC.

Und in den Fuses ist als Taktquelle ein externer Quarz konfiguriert. Haste den bei deinem Test auch drangehabt?
Außerdem immer 100 nF so dicht wie möglich am AVR zwischen VCC und GND hängen, sonst kann die Kiste schwingen.

Außerdem ist ja auch der Bootloader in den Fuses aktiviert. Keine Ahnung, welcher das ist und was er macht... Vielleicht hängt dein AVR auch im Bootloader fest?

Mach doch mal nen Chip Erase und setz die Fuses so, dass der Bootloader testweise deaktiviert ist, und er den internen RC-Oszillator als Taktquelle benutzt.
(LFUSE: 0xE4; HFUSE: 0xDD, zur leichten Berechnung der Fuses siehe https://www.engbedded.com/fusecalc/)
Dann sollte er eigentlich blinken...

Gruß!

[bkifft]

Probier mal https://github.com/bkifft/mk312-bt/tree ... libc_based.
Damit Programmier ich immer die BT-Module. Hat auch Ausgabe auf dem LCD.

Und paste mal komplet Aufruf und Ausgabe von avrdude, also für fuses und binary.

[tobias966]

habe auch den MK-312BT gebaut und dasselbe Problem. Im Display sind in der oberen Zeile nur weiße >Kästchen zu sehen. Wenn ich den Kontrast noch weiter reduziere erscheinen auch in der unteren Zeile weiße Kästchen. Habe auch alle verfügbaren bin Dateien installiert leider ohne Erfolg.
Wäre schön wenn jemand noch einen Tip hätte

[Bombenleger802]

Hallo zusammen,

also als Erstes muss ich mich mal entschuldigen, dass ich erst so spät antworte. Durch eine Studienarbeit hatte ich leider ziemlich Stress.

Zudem ist es mir eine Ehre von dem Admin so eine nette Antwort zu bekommen, danke Paul. Den Reset Widerstand, sowie die Kapazitäten habe ich vergessen. Ich vermute zudem, dass ich den Atmega geschrottet habe, weil er am Ende nicht mehr von AVR Dude erkannt wurde. Bis zum jetzigen Zeitpunkt habe ich das Projekt jedoch pausiert.

Damit ist jetzt Schluss! Ich werde die vielen Ideen die nächsten Tage versuchen umzusetzen (könnte etwas länger dauern, wenn ich nochmal bei Mouser bestellen muss). Toll, dass doch ein paar Leute diesesTeil nachbauen wollen.
@bkifft danke für den Tipp, das werde ich ausprobieren. Damit könnte ich einen Hardwaredefekt zumindest ausschließen.
@tobias966 Welche Layout Version verwendest du? Hast du ebenfalls die Gerber Dateien direkt an JLC PCB geschickt? Ich vermute langsam, dass die Platine einen Fehler im Layout hat. Vielleicht verwende ich jetzt mal die V1.3 und lasse eine neue anfertigen.
Ich halte euch ab jetzt auf jeden Fall wieder auf dem laufenden

Gruß
Luca

[Bombenleger802]

Hallo zusammen,

ich habe heute nun das 3. MK312 gebaut.
- Habe neue PCBs fertigen lassen, um hier einen defekt aus zu schließen
- Neue Teile verwendet
- Neues Frontpanel

Eigentlich habe ich damit alle Hardware Fehler ausgeschlossen, welche überhaupt eintreten können. Das einzige sind wie gesagt die MOSFETs. Ich verwende halt keine IRL520N sondern eine Alternative.

Die Software von bkifft habe ich auch schon versucht, leider ohne Erfolg. Ich bekomme auch hierkeinen Output.

Bitte helft mir. Ich will das Projekt eigentlich nicht aufgeben, dafür steckt mittlerweile viel zu viel Arbeit drin.

Danke euch

Gruß
Luca

[Heisath]

Hi,

Ich bekomme auch hierkeinen Output.

Keinen Anzeige auf dem Display? Oder einfach nur keinen Output an den Klinkenbuchsen?

Du müsstest den Fehler halt mal weiter eingrenzen und mMn. durch Messen und nicht wildes probieren / tauschen einiger Teile.

- Ein einfaches Programm schreiben (gabs doch weiter oben schon) und auf den µC flashen, dann aufm Steckbrett oder so gucken ob deine Art den zu flashen überhaupt funktioniert
- Das eigentliche Programm auf den µC schreiben und mal schauen ob er dann überhaupt irgendwas macht. Vielleicht mal nur mit dem Display verbinden? (nicht das da ein Fehler in den Platinen ist, der dir sofort den µC grillt).
- Ohne µC mal die Platinen an Strom hängen, Stromaufnahme überwachen und an allen Pins die Spannungen nachmessen
- µC auf die Platine stecken, aber die Ausgangstransistoren (Leistungsstufen) weglassen, schauen ob das Display geht und überall die richtigen Signale ankommen

Ohne einen systematischen Ansatz wird es schwer hier den Fehler aus der Ferne zu diagnostizieren.


lg,

[Bombenleger802]

Hi,
also erstmal danke für die schnelle Antwort.
Mit "keinen Output" meine ich, dass ich keine Displayausgabe habe, im Grunde der gleiche Fehler wie am Anfang. In der ersten Nachricht habe ich das recht genau beschrieben.

Durchgemessen habe ich bei jedem Board mit diesem Fehler die Spannungen der Spannungsregler, sowie alles was sich gut messen lässt. Auf der Arbeit habe ich zudem mit dem Oszi mir mal die Ein/Ausgänge der Trafos angeschaut, hier war leider keine Anrampung oder irgendeine Art von Pulsen zu erkennen.

Ich vermute schwer, dass der Atmega nicht richtig aufstartet, aber ich habe keine Ahnung wieso. Das Projekt gibt nur ein .bin File als Firmware frei.

Teile habe ich schon mehrere Male gewechselt. Hardware sollte eigentlich i.O. sein. Und die 4 Baugleichen MOSFETs sollten eigentlich nicht so einen Fehler werfen. Wenn dann einen Fehler 20 oder?

Gruß

[Heisath]

Ich kenne mich mit dem Gerät nicht aus, daher keine Ahnung was "der Fehler 20" sein soll.

Beim Code von bkifft gibts ja auch die Quellen, vielleicht den Code mal soweit abspecken bis es läuft?
Es ist ja vermutlich entweder deine Art den µC zu programmieren oder der Code kaputt. Die Hardware kanns beim 3. Neubau ja kaum noch sein