ich verwende gerade den ATmega324PA in einer neuen Anwendung und m=F6chte=
dort einen IAP-Lader (f=FCr Software-Updates im laufenden Betrieb) einbau= en.
Der IAP-Lader liegt am oberen Ende des Flash (im RWW Bereich) und macht alles exakt so, wie es im Datenblatt und diversen Application Notes beschrieben ist.
Trotzdem scheint der SPM Befehl einfach gar nichts zu tun. Es wird weder des Flash gel=F6scht, noch neue Daten hineingeschrieben. Es gibt auch keine me=DFbare Verz=F6gerung zwischen der Ausf=FChrung von SPM und dem anschlie=DFenden Inaktivwerden von SPMEN.
Ich habe mir einige (angeblich funktionierende) Bootlader angesehen, aber dabei keinen Unterschied gefunden. Woran k=F6nnte es liegen, da=DF d= as Flash sich partout nicht l=F6schen bzw. schreiben l=E4=DFt?
Hier der Code (IAPBase liegt auf Wort-Adresse 0x1E00):
--
; Erase Flash from 0x0000 up to IAP loader:
...
Das Ende des Flashes und die Bootloader Section liegen aber im NRWW Bereich.
Sieht auf den ersten Blick nicht verkehrt aus. Vielleicht doch ein Trivialproblem: Du machst rcall/ret, d.h. der Stackpointer muss vorher initialisiert werden. Und die Interrupts sollten deaktiviert sein damit es keinen SPMEN Timeout gibt.
Oder ganz anders: Es wurde mal eine falsche Adresse uebergeben und dadurch hat sich der Bootloader selbst zerschossen.
Die gibt's nur bei den ganz kleinen AVRs. Bei den großen (wie der '324 es ist) gibt es BOOTSZ0/BOOTSZ1, die die Größe des Bootloader-Bereichs festlegen. Allerdings ist der voreingestellte Wert im Auslieferungszustand so, dass der gesamte NRWW-Bereich als Bootloader-Bereich zugelassen ist.
Rein von dem, was du da aufgeschrieben hast, ist nicht klar, warum es nicht funktioniert.
Nat=FCrlich ist der Stackpointer gesetzt, der ganze Rest des IAP-Laders (incl. serieller Kommunikation mit definiertem Protokoll) l=E4uft auch perfekt. Interrupts sind global aus, die kann ich im ganzen Lader nicht brauchen (Kommunikation l=E4uft vollst=E4ndig per Polling).
Schon der frisch per ISP geflashte Lader ist nicht in der Lage, auch nur eine einzelne Page ganz unten (weit abseits des Laders selbst) zu l=F6sch= en. (Au=DFerdem lehnt der Lader nat=FCrlich schon bei der Kommunikation Adres= sen ab, die ihm gef=E4hrlich werden k=F6nnten.)
CPU mal wechseln. Klappt das nur mit einer bestimmten CPU nicht oder ist das ein generelles Problem dieses Typs/HertellerS?
Kenne den AVR nicht, hab früher (tm) schon mal ähnliche Probleme mit ADuC 812(?) gehabt. Prototyp und 1. Serien gingen. Dann waren einige CPUs serienmässig mit dem Problem behaftet.
Typische support Antwort ... das kann garnicht sein... Sie sind der Erste, der sowas behauptet... liegt an ihrer SW... bei allen anderen gehts... ...und nach einem halben Jahr gabs dann ganz kleinlaute ECOs :( Aber auch ein redesign mit SiLabs :)
Dann solltest du vielleicht auch mal die Hardware verdaechtigen, chinesischer Fake macht bekanntlich auch vor AVRs nicht Halt. Statt einen voellig falschen Chip einzubauen kaufen die vielleicht mittlerweile auch halbkaputten Ausschuss auf (und "entsorgen" ihn dann bei ihren Kunden).
Auch denkbar waere ein noch undokumentiertes Errata. Das gab es IIRC schonmal bei einem aelteren Modell, das liess sich nur bei bestimmten Spannungen programmieren, also nicht im gesamten Bereich den das Datenblatt spezifizierte.
Die, die ich von diesem Typ habe, stammen alle aus einer Charge. Ich k=F6nnte h=F6chstens mal einen 164P oder einen 644P testen, davon habe ic= h Muster.
Ein generelles Problem sollte es eigentlich nicht sein, denn angeblich gibt es viele IAP-f=E4hige Produkte auf AVR-Basis.
( =20
Ich w=E4r schon froh, wenn der Atmel Support /=FCberhaupt/ irgendetwas au= f meine Anfrage antworten w=FCrde. :-\ Keinerlei Reaktion bislang.
Nichtmal eine Ticketnummer? Dann hast du was falsch gemacht, denn die wird automatisch vergeben. Ansonsten ist die Policy, glaub ich, dass sich innerhalb von 3 Werktagen jemand mit deinem Problem befasst haben soll.
Ich habe mal spaßeshalber einen ATmega324P in einen STK500 gesteckt (der PA sollte dazu logisch identisch sein, da es sich nur um eine "die shrink"-Version handelt), und dort das folgende Programm geflasht (sorry, ist in C/AVR-GCC, zum Assembler bin ich zu faul):
Hast Du's mal über einen Distri versucht? MSC ist meines Wissens nach recht hilfsbereit. Für direkten Support von Atmel sind Deine Stückzahlen u.U. zu klein ;)
Doch, Ticket habe ich - aber sonst noch nichts. Nach gut zwei Tagen ist der Fall immer noch "Open" - aber gut, bis morgen h=E4tten sie demnach noch Zeit. Drei Tage k=F6nnen in so einem Fall aber schon sehr lang werden... :-\
Hier ist =FCbrigens aktuell auch ein 324P drin, Fehlangabe meinerseits.
Vielen Dank f=FCr den Testcode. K=F6nntest Du mir rein informativ noch da= s Assemblerlisting aus dem Compiler schicken? (Mailadresse funktioniert.)
Wenn der Loader im NRWW liegt, liegt er dann nur in der App Table oder tatsächlich in der BL Section? SPM muss im Bootloader liegen, nur NRWW alleine ist nicht ausreichend (S.11: "The SPM instruction that writes into the Application Flash memory section must reside in the Boot Program section.")
Im Code kann ich keinen Fehler finden, allerdings könnte man den auch etwas hübscher schreiben, so daß er automatisch auf jede Pagegröße paßt. Aber das ist Kosmetik und hat mit dem geschilderten Problem sicher erstmal nix zu tun.
Das Thema Interrupts wurde ja bereits im Thread behandelt, scheint soweit auch OK zu sein. Aber zur Sicherheit kann es nicht schaden, DoSPM testweise mit einem kleinen "cli" direkt vor "out SPMCSR,r16" zu ergänzen. Der eine Takt mehr macht den Kohl sicher nicht fett, aber er sorgt dafür, daß im entscheidenden Moment sicher nix schief geht.
Interessant wäre vielleicht noch die Stromversorgung. Mit welcher Spannung läßt du das Ding eigentlich laufen? Schonmal eine andere (höhere) probiert?
Sowas kenne ich auch, da musste vor und hinter dem out ans Flash noch ein NOP stehen, sonst kam die statemachine im Flash aus dem Tritt.
Die Beispiele waren alle in C und relativ umständlich, von Hand per ASM waren da nur die Minimalzahl von Taktzyklen drin. Gelernt ist gelernt :(
Das erinnert mich an ein anderes Flash Problem. uC hab ich vergessen, aber da musste der PF und der brownout detector explizit vorher abgeschaltet werden, sonst murkste er dazwischen. Aber nicht unter allen Bedingungen. War auch so ein Lotto Generator, der schlaflose Nächte bereitet hat. Viel später kamm dann eine Errata, wo das beschrieben wurde. Schienen im Endeffekt Masse Probleme im Chip gewesen zu sein. Die rel. hohen Ströme fürs flashen machte den Detektor wuschig!
Sieh mal nach, was da auf dem AVR alles so gespielt wird.
AVRs sind bezüglich Errata eher unspektakulär, auch Flashen bis zur minimal garantierten Versorgungsspannung ist dort kein Thema. Irgendwo auf avrfreaks.net gibt's auch noch eine Liste inoffizieller Errata (teilweise sind sie dann später auch offizialisiert worden).
Da mein Code auf seinem Controller jedoch funktioniert, muss das Problem woanders liegen.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.