HC-06 factory reset

[Herbert (Gast)]

Hallo,

wie kann ich bei einem HC-06 (Bluetooth-Modul) einen factory reset 
machen? Also so, dass alle Werte wieder auf den Default gesetzt werden. 
Ich habe (vermutlich) durch einen Übertragungsfehler die Baudrate 
verstellt (auf einen unbekannten Wert, der sich auch durch langes 
Herumprobieren nicht erraten lässt. Jetzt kann ich keine neue Baudrate 
einstellen, weil das Modul keine Befehle mehr annimmt.

[Henning (Gast)]

Ein kurzer Blick in das Datenblatt hat mir verraten, dass es nur zwölf 
verschiedene Baud Raten geben soll. Hast du diese (plus drei 
Paritätsmodi) schon versucht? Der HC-05 soll wohl etwas freier sein in 
der Konfiguration der Baudrate.

Alternativ könntest du das an einen Logic Analyser anschließen und 
manuell schauen welche Baudrate du eingestellt hast. Diese kleinen USB 
Dinger reichen dafür. Kriegst du das Modul irgendwie zum senden, gibt es 
vielleicht eine Boot Nachricht?

[Herbert (Gast)]

Habe leider keinen Logikanalysator.

Momentan hängt das Modul noch an einem ATMega. Ich habe schon unzählige 
Module "in system" mit anderem Namen und anderer Baudrate versehen. Nur 
diesmal ist irgendwas schief gegangen.

Ich habe natürlich schon alle Baudraten durchprobiert, wobei die ganz 
schnellen wahrscheinlich unzuverlässig sind. Wenn es auf die schnellste 
Stufe geschaltet hat, werde ich per AT-Befehle nicht weiter kommen. 
Deswegen die Frage nach einem Factory Reset.

[Herbert (Gast)]

Zu allem Überfluss läuft der Mega mit internem RC-Oszillator, der geht 
ja auch nach dem Mond. Ich habe aber durch weiteres Herumprobieren 
herausgefunden, dass das Modul wohl "AT+BAUD9" verstanden hat, also 
jetzt mit 230400 läuft. Jedenfalls kommen manchmal lesbare Daten an, 
wenn ich den UART mit diesem Wert initialisiere und dann in einer 
Schleife OSCCAL durchorgele... irgendwo scheint er dann das korrekte 
Timing zufällig zu treffen. Soweit funktioniert mein Plan zumindest 
schonmal...

[Stefan F. (Gast)]

Es wird wohl Zeit für einen Taktgeber mit Quarz.

UART mit R/C Oszillator ist ohnehin keine gute Idee - auch nicht bei 
geringen Bitraten.

Die Ungenauigkeit des 8Mhz R/C Oszillators ändert sich nicht, wenn du 
die Bitrate änderst. Also ist die Aussage, dass niedrige Bitraten 
weniger Problematisch seien, als hohe Bitraten, einfach falsch.

Im Datenblatt des AVR findest du Tabellen, wie weit die tatsächliche 
Biterate vom Soll abweicht, wenn der µC mit 8 oder 1Mhz getaktet wird. 
Dazu addierst du noch die Ungenauigkeit des R/C Oszillators.

Bei mehr als 1% Abweichtung (also immer) ist mit Fehlfunktionen zu 
rechnen. Bei mehr als 5% Abweichung ist damit zu rechnen, das die 
Fehlerrate unerträglich wird. Ab 10% ist graantiert, dass die 
Schnittstelle versagt.

Du wirst sehen, dass es durchaus auch hohe Bitraten gibt, die nicht 
schlechter dastehen, als niedrige Bitraten.

Übrigens kann man den R/C Oszillator auf 7,3728 Mhz umkalibrieren, dann 
sind alle gängigen Baudraten mit 0% Abweichung möglich. Natürlich 
zuzüglich der Abweichungen durch Temperaturdrift.

Also wenn schon R/C Oszillator, dann stell ihn auf 7,3728v Mhz um. Die 
Mühe lohnt sich.

So macht man das: http://www.atmel.com/images/doc2555.pdf

[Herbert (Gast)]

Hallo, es ist sehr viel komplexer. Es hängt bereits ein Uhrenquarz am 
Mikrocontroller. Die Anwendung kalibriert OSCCAL mit dessen Hilfe auf 
7833600 Hz.
Einzig meine Firmware zum einmaligen Setzen der Baudrate konnte das noch 
nicht, daher die Probleme.