Hallo,
für eine Schaltung mit einem ATxmega64A3 habe ich eine Software
geschrieben, die den RTC nutzt. Klappt soweit, schön!!
Nun benutze ich einen Bootloader (chip45boot2), der lädt das Programm an
Adresse 0000 und läuft da los. Leider "tickt" mein RTC nun nicht mehr.
Nach meinen Nachforschungen ist der Systemtakt wie ohne BL (2MHz), aber
mit dem BL zählt der counter (RTC.CNTL) nicht mehr hoch. Hab auch mal
den internen 32KHz RC Oszillator versucht, keine Änderung.
Es scheint ein Register im BL gesetzt zu werden, das den RTC verriegelt,
leider finde ich nichts im Internet oder Dokument, was denn noch gesetzt
sein muss, damit der RTC läuft. Meine Initialisierung ist so:
1
intmain(void)
2
{
3
PR.PRPC=0x7F;//turns off all USART clocks
4
PR.PRPD=0x7F;
5
PR.PRPE=0x7F;
6
PR.PRPF=0x7F;
7
PR.PRPA=7;//turns off all analog stuff
8
PR.PRPB=7;
9
PR.PRGEN=0x5B;//allow RTC only
10
11
set_sleep_mode(SLEEP_MODE_PWR_SAVE);
12
13
PORTF.DIR=0x33;
14
PORTF.PIN7CTRL|=PORT_OPC_PULLUP_gc;
15
PORTF.PIN6CTRL|=PORT_OPC_PULLUP_gc;
16
PORTF.PIN3CTRL|=PORT_OPC_PULLUP_gc;
17
PORTF.PIN2CTRL|=PORT_OPC_PULLUP_gc;
18
//initialize RTC for 16384 HZ and 256 tick for 64 IRQs per second
19
OSC.XOSCCTRL=OSC_X32KLPM_bm|OSC_XOSCSEL_32KHz_gc;
20
OSC.CTRL=OSC_XOSCEN_bm;
21
while(OSC.STATUS&(OSC_XOSCRDY_bm));//wait until osc. is ready
RTC.INTCTRL=RTC_OVFINTLVL_HI_gc;//High Level for overflow interrupt
26
//RTC initialized!
Der RTC tickt hier nur dann nicht, wenn über den BL programmiert wurde!!
Was könnte hier noch fehlen um die Änderungen des BL abzuschalten?
Alle gefundenen Beispiele sind so, ein weiteres Register habe ich nicht
gefunden. Der BL nutzt auch die PLL, da habe ich etwas gesehen, PLL
verriegelt RTC, komme da aber auch nicht weiter.
Wer kennt so ein Problem?
Besten Dank,
Gruß
Thomas
Hallo,
typischer Kandidat für sowas sind diese PowerSave-Modi. Man kann die
Clk-Source für die komplette Peripherie abschalten, was bei einem
BoardInit() meistens gemacht wird (Wenn man ASF benutzt). Wenn das im BL
passiert müsstest du es in deinem Programm wieder anschalten. Mit ASF
dürfte es ca. so aussehen:
Hallo,
danke für den Vorschlag, aber dieser Aufruf sollte den RTC Takt
einschalten (klappt auch):
PR.PRGEN = 0x5B; //allow RTC only
Wenn ich das entsprechende Bit für RTC auf 0 setze ist mein RTC aus. So
wie hier beschrieben ist RTC an und funktioniert ohne BL.
Die vorgeschlagene Funktion finde ich nicht da ich das ASF nicht nutze..
Beinhaltet die noch etwas anderes?
Hallo,
ja stimmt das sollte es tun. Wobei das 5te Bit bei dir auf auf 0 gesetzt
wird (ich weiß nicht ob das Auswirkungen hat).
Du könntest ein Programm schreiben das dir alle "Register"inhalte
ausgibt und dann einfach den Inhalt mit und ohne BL vergleichen. Wobei
ich nicht weiß ob die alle geordnet/sinnvoll im Speicher angeordnet
sind.
(Wenn das funktionieren sollte wäre ich am Programm interessiert)
Solche Geschichten das der Watchdog eingeschaltet wird und du dann nur
den Reset jeweils siehst hast du ausgeschlossen?
Nachtrag: Im der EnableRoutine vom ASF wird vorher noch das SReg
gesichert und die Interrupts deaktiviert bzw. wieder aktiviert und das
SReg zurückgeschrieben. Auch wenn du das ASF nicht benutzen willst ist
es manchmal ganz hilfreich wenn du von einer "Klarnamen"-Funktion auf
die Registerebene kommen willst ohne vorher das halbe Datenblatt zu
lesen (in Kombination mit dem Atmelstudio).
Hi,
na, alle Register auslesen lassen und dann den Unterschied vergleichen
...
Ist mir recht aufwändig!
WD Reset ist nicht das Problem, wenn ich z.B. nur ein Bit toggeln lasse
so läuft das ohne Unterbrechung. Nur der RTC tickt nicht.
Da suche ich mal einen anderen BL und schaue mal ob das damit klappt.
Irgendo habe ich etwas gelesen dass die PLL den RTC verriegelt, habe
aber nicht so genau verstanden unter welchen Bedingungen.
Wenn sonst keiner was weiß suche ich mir nen anderen BL und teste es
damit.
Guten Abend...
Thomas
Frage. Tickt die RTC wirklich nicht (daher sie löst auch kein Interrupt
aus) oder liest du nur das CNT Register aus um zu sehen ob die RTC
tickt?
Ich frage nur wegen Errata
1
20. RTC Counter value not correctly read after sleep
2
3
If the RTC is set to wake up the device on RTC Overflow and bit 0 of RTC CNT
4
is identical to bit 0 of RTC PER as the device is entering sleep,
5
the value in the RTC count register can not be read correctly within the
6
first prescaled RTC clock cycle after wakeup. The value read will
7
8
be the same as the value in the register when entering sleep.
9
The same applies if RTC Compare Match is used as wake-up source.
10
11
Problem fix/Workaround
12
Wait at least one prescaled RTC clock cycle before reading the RTC CNT value.
Ansonsten sollte die PLL die RTC nicht sperren, tut sie bei mir
zumindest nicht.
EDIT: Wobei wenn ich das jetzt nochmal so lese, dass das Errata dann
wohl doch nicht dein Problem ist.
EDIT2: Welche Version hast du von diesem komischen chip45boot2? In 2.9N
wurde irgendwas in Verbindung mit A3 Devices gefixed.
Hallo Timmo,
ich verwende diese Version:
chip45boot2_atxmega64a3_uartF0_v2.9N.hex
Es passiert beides: Kein RTC Interrupt und genau deshalb hab ich mal zum
Debuggen den CNT ausgelesen. Wenn ich ohne BL brenne bekomme ich immer
verschiedene Werte, mit BL immer den selben. Er zählt also nicht auf und
deshalb kommt kein Interrupt.
Inzwischen habe ich XBOOT gefunden, damit gibt es kein Problem. Ist zwar
nicht so schön mit GUI und so, aber avrdude mit den Parametern packe ich
dann in eine Batch Datei (es werden viele Geräte gebrannt). Leider kann
der XBOOT keine Auto Baudrate, aber das macht nix.
Denke das wars dann, danke an alle die sich bemüht haben.
Die Geräte seht ihr bei www.rallyenavigationsolutions.com
Wir haben bisher einen Atmega169PA verwendet, aber der hat eine Macke
beim 8Bit Timer. Hatte mal vor Jahren einen Beitrag hier, das Problem
wurde auch nie gelöst. Der XMega macht es nun fehlerfrei..
Gruß
Thomas
Hallo Thomas,
welche Probleme hattest du mit dem Atmega169PA bezüglich des 8Bit
Timers?
#"Wir haben bisher einen Atmega169PA verwendet, aber der hat eine Macke
#beim 8Bit Timer. Hatte mal vor Jahren einen Beitrag hier, das Problem
#wurde auch nie gelöst. Der XMega macht es nun fehlerfrei.."
Ich kann diesen Beitrag leider nicht finden.
Ich habe von dir einen anteren Beitrag gefunden, bei dem hattest du den
ATmega162V verwendet, hat der auch das gleiche Problem?
Gruß Sven
Hallo,
wir sind vom 162 umgestiegen zum 169 weil der
1. mehr Pins hat, damit kann jedes Segment des LCD angesteuert werden
2, er weniger Strom braucht
Leider kommt es da sporadisch zu falsch ausgelesenen Werten des Timers.
Diese Werte werden zur Berechnung der Geschwindigkeit herangezogen,
deshalb kommen dann und wann irrwitzige Werte für die Geschwindigkeit
heraus. Das kommt aber nur sporadisch und ist nicht nachvollziehbar.
Soweit ich es erinnere gab es das beim 162 nicht.
Inzwischen läuft es aufm XMEGA und da ist das Problem auch nicht, ich
kann da den 16Bit Timer RTC nutzen und muss nicht die Überläufe zählen.
Hoffe die Info hilft weiter.
Gruß
Thomas
Überläufe zählen allein reicht nicht, der Interrupt erfolgt ja nach dem
Überlauf.
Man muß den Timer mit dem Interruptzähler entsprechend verknüpfen, damit
man gültige Zeitstempel erhält:
Beitrag "AVR Timer mit 32 Bit"
Hallo Thomas,
vielen Dank schon mal für deine Antwort. Ich habe deine Software
getestet auf einem Atmega162V
Beitrag: Standard LCD mit Controller steuern
Ich habe zwei Probleme:
1.) Ich denke es ist ein Software-Bug aber ich kann ihn nicht finden.
die Segmente 2B,3F und 3G leuchten immer. Ich habe schon mit dem Oszi
gemessen, die 3 jeweiligen Pins geben immer 5Volt aus (toggeln nicht
mit, siehe Anhang). Auch der Doppelpunkt macht Probleme, der verhält
sich elektrisch wie wenn er nicht angeschlossen wäre und optisch zuckt
er ganz leicht - hat aber verbindung zum MC pin. Die Belegung ist wie in
deiner Excel Tabelle und die Belegung meines LCDs stimmt mit deinem
überein.
2.) Die Taktfrequenz zu hoch? Die Uhr läuft ca. doppelt so schnell wie
sie sollte. Bei den Oszi Messungen passt die Frequenz, oder? Ich habe
einen 4,194304MHz Quarz in mein STK500 gesteckt und die Jumper
ensprechend umgesteckt. Hast du eine ahnung was da faul ist?
Vielen Dank für die Hilfe
Gruß Sven
Hallo Sven,
das Design ist für die folgenden Fuses gemacht:
Takt ist durch 8 geteilt, also die effektive Frequenz ist etwa 500KHz.
JTAG muss abgeschaltet sein!!!!!!!!
Die Segmente die immer leuchten sind so wegen JTAG, der blockiert da
vier Bits von PortC PC4 bis PC7. Da ist auch der Doppelpunkt dabei. Also
JTAG AUS!
Miss mal die Frequenz der Segmente die richtig funktionieren (an oder
aus). Da sollte 32Hz liegen.
Wenn die Uhr doppelt so schnell läuft, so sind bestimmt da 64Hz zu
messen.
Wegen doppelt scheint der auf 1MHz zu laufen, Fuses einstellen auf
Quarzbetrieb und Teilung durch 8, meine Fuses hab ich mal angehängt
(PonyProg).
Hier siehst du meinen Prototypen auf Lochrsater (weiter unten..)
http://www.advrider.com/forums/showthread.php?t=400288
Dann sollte es klappen, viel SPaß
Gruß
Thomas
Thomas Schattat schrieb:> Leider kommt es da sporadisch zu falsch ausgelesenen Werten des Timers.> Diese Werte werden zur Berechnung der Geschwindigkeit herangezogen,> deshalb kommen dann und wann irrwitzige Werte für die Geschwindigkeit> heraus. Das kommt aber nur sporadisch und ist nicht nachvollziehbar.> Soweit ich es erinnere gab es das beim 162 nicht.>> Inzwischen läuft es aufm XMEGA und da ist das Problem auch nicht, ich> kann da den 16Bit Timer RTC nutzen und muss nicht die Überläufe zählen.
Hallo Thomas,
vielen Dank für deine Antwort. Der Umstieg auf den XMEGA hast du also
nur wegen des 16Bit Timers gemacht oder? Bis auf das Timer Problem wäre
der 169 eigentlich ideal für deine Anwendung oder?
Thomas Schattat schrieb:> wir sind vom 162 umgestiegen zum 169 weil der>> 1. mehr Pins hat, damit kann jedes Segment des LCD angesteuert werden> 2, er weniger Strom braucht
Brauch der XMEGA nochmal weniger Strom als der 169 macht das keinen
Unterschied?
Danke schön
Gruß Sven
Hi Sven,
der XMEGA läuft mit etwas weniger Spannung und braucht weniger Strom als
der 169. Hauptgrund war aber der 16Bit Timer.
Klappt das nun mit dem 162 wie beschrieben?
Gruß
Thomas
Hi Thomas!
Vielen Dank für deine Hilfe! So macht lernen Spaß :)
Wenn du von ATMEGA auf XMEGA umsteigst, ist das sehr aufwändig oder
kannst du deine Software 1zu1 draufspielen? Die Hardwarebelegung wird ja
gleich sein oder?
Gruß Sven
Sven Wiedemann schrieb:> Hi Thomas!>> Vielen Dank für deine Hilfe! So macht lernen Spaß :)>> Wenn du von ATMEGA auf XMEGA umsteigst, ist das sehr aufwändig oder> kannst du deine Software 1zu1 draufspielen? Die Hardwarebelegung wird ja> gleich sein oder?
Hardwarebelegung? Weder Pinning noch Peripherie sind gleich. Der Xmega
ist ganz anders aufgebaut als die Megas. Man muss schon einiges ändern
an der Software damit das so funktioniert wie vorher. Aber im Prinzip
ist es relativ überschaubar.