Ich dabei, den PIC12F509 mal näher unter die Lupe zu nehmen. Dabei ist mir aufgefallen, dass es einen Flashbereich gibt, der im Datenblatt als "reserviert" gekennzeichnet ist. 0x400-0x403 ID 0x404 OSCAL BACKUP 0x405-0x43F reserved Ich nenne den Bereich mal "high flash" (HF) Es ist möglich, diesen Bereich zu beschreiben (12 Bit) und im Programm Mode (/MCLR = Vpp) die SW auszuführen. Das ganze läuft unabhängig von der Codeprotection. Auch läßt sich ein laufendes Programm anhalten (/MCLR VCC -> VPP), man kann das die SW im HF ausführen und durch absenken /MCLR VPP -> VCC die "normale" SW fortsetzen. Man kann auch vom HF in den normalen Bereich springen. Umgekehrt geht das anscheinend nicht. Dabei ist zu beachten, dass bei wenn SW im HF ausgeführt wird das BIT "STATUS,6" (eigentlich PA1) ausgewehrtet wird (also setzen, wenn man im HF springen will. Der Programmcounter wird anscheinend auf einen, evtl. den regulären Stack gerettet. Alle anderen Register scheinen nicht gesichert zu werden. Man muß anscheinend also so vorgehen, wie bei einer normalen ISR (Interrupt service routine). Lauf Microchip unterstützt der PIC12F509 kein HW debugging. Es gibt aber einen speziellen Debugg Controller, der dann Anstelle des PIC12F509 eingesetzt wird. Es sieht aber eben so aus, als ob doch eine gewisse Funktionalität vorhanden ist. Interessant wäre jetzt, was noch alles möglich ist, wie z.B. single step. Ich sehen in der ganze Sache auch eine gewisse Gefahr für meine eigene SW, da es einem Angreifer an jeder Stelle möglich ist, meine SW anzuhalten und den RAM-Inhalt auszulesen oder zu modifizieren, und ggf. meine SW dann weiterlaufen lassen. Eine Möglichkeit ist natürlich, den HF Bereich auszunullen. Evtl. gibt es aber undokumentierte ICSP Befehle mit denen ich z.B. diesen Bereich wieder getrennt löschen kann. Desweiteren haben die "reservierten" Protect Bits eine HF-Relevante Bedeutung. Hat da jemand Erfahrung oder das schon mal näher untersucht ? Was ist noch alles möglich, besonders im Bereich "debugging" ? Walter.
Kannst du bestätigen, dass dieser Assemblercode den mal jemand gepostet hatte auch wirklich ausgeführt wird? Da gabs ja diesen schlecht geschützten Bereich im Controller den man auslesen konnte. Dort waren afaik Schieberegister mit Rückkopllung drin. Aber wird das auch ausgeführt? Welche Daten kannst du bisher auslesen? Nur RAM oder auch Register, Timer etc? Klappt schreiben auch? Sind Sprünge an Zieladressen möglich?
Walter, probier doch mal das nicht dokumentierte Bit 11 des Configuration Registers zu setzen: bit 11: BKBUG: On-chip Debugger Mode (This bit documented as reserved in data sheet) 1 = On-chip debugger functions not enabled 0 = On-chip debugger functional. OnChip Debug Spec. siehe angehängte Datei. Ist zwar für den PIC16F87x, funktioniert aber vielleicht auch für den 12F509. Gruß uzi
"Auch läßt sich ein laufendes Programm anhalten (/MCLR VCC -> VPP), man kann das die SW im HF ausführen und durch absenken /MCLR VPP -> VCC die "normale" SW fortsetzen." Mach den VPP-Puls kürzer als einen Befehlszyklus. Ich vermute, der wird intern auf CLK synchronisiert. Damit könnte man Single-Step machen.
Zur Info: dieser Thread ist ein Branch von Beitrag "Was ist aus dem Thread der MeteoData geworden?" Endlich bin ich dazugekommen, einen normalen PIC mit einem atMega32 zu verkuppeln. Programmieren geht, löschen auch, und es geht auch was mit DataRemanance. Wie Walter bereits geschildert hat, erscheinen die Bits bei Reprogrammieren scheinbar zufällig. Kann sein, dass MC absichtlich als Gegenmaßnahme unterschiedliche Schwellen eingebaut hat. Auslesen mit verschiedenen Spannungen und eine statistische Untersuchung stehen als nächstes an. Ich bin zuversichtlich... Bisher habe ich allerdings noch ohne CP gearbeitet. Mal sehen, wie lange man löschen muss, bis diese zurückgeht. In einem Paper habe ich auch von Versuchen bei verschiedenen Temperaturen gelesen. Es dauert nicht mehr lange.... > Laut Microchip unterstützt der PIC12F509 kein HW debugging. > Es gibt aber einen speziellen Debugg Controller, der dann > Anstelle des PIC12F509 eingesetzt wird. Da spielt der PIC16F505 eine gewisse Rolle, den haben sie gemacht, damit man ICD machen kann, ohne die normalen 8 Pins zu stören. > Diese kann dann das Flash auslesen. Wie es in der Maskenversion > (ROM, also kein Flash) aussieht, weiß ich nicht. Das ist die Frage, ob es eine Maskenversion ist. Einerseits die Frage, ob MT das Risiko eingehen wollte, zumal ja 6580001 auf dem Chip steht. Andererseits ist der 6580 der seltenste DCIC, wenn es eine Maske wäre, wäre er billiger und häufiger eingesetzt. Was passiert eigentlich, wenn man folgendes macht: Start CALL Label1 ret <<-- wohin spring er hier? Label1 CALL Label2 ret Label2 ret
ein weiterer Ansatz wäre, nach undokumentierten Assembler Befehlen zu suchen. Laut Datenblatt sind ca.30 Befehle dokumentiert. Ein Befehl besteht aus 12 Bit. Die Befehle, die in den ersten 4 Bit 0001-1111 haben sind alle dokumentiert. Von den Befehlen, die mit 0000 anfangen sind etwa 200 dokumentiert (also 200 Möglichkeiten in 10 Befehlen). Bleiben also ca 50 mögliche Kombinationen, die nicht beschrieben sind. Im Debug File von UZI wird z.B der Befehl 0x00F verwendet. Der Disassembler kennt ihn nicht. ... 00aa 0443 clrz 00ab 0650 btfsc 0x10,2 00ac 0543 setz 00ad 05e5 bsf 0x05,7 00ae 000f db 0x00,0x0f <-- 00af 05e4 j0af: bsf 0x04,7 ... davor werden anscheinend die Flags und Register wiederhergestellt, könnte also schon so etwas sein wie "return from debug, but do not tell anybody..." ;-) Das müsste gerade im Zusammenhang mit Speicher 0x405+ und MCLR=Vpp untersucht werden. Soweit die Gedanken zum Tag. Walter.
uzi schrieb: > Hier noch ein paar Infos zum Debuggen von Pics: > > Beim MPLAB ICD2 wird ein kleines "Zusatzprogramm" zusätzlich zur > eigentlichen Applikations in den PIC geladen und dann der Debug-Mode > aktiviert und das Zusatzprogramm angesprungen. > (Entnommen aus der Hilfe zum MPLAB ICD2) > > Das "Zusatzprogramm" und ein paar weitere Files befinden sich in der > angehängten Zip-Datei. > Soweit ich das verstanden habe funktioniert das aber nicht mit > Code-Protection :-(( > Wird uns also vermutlich nicht viel weiter bringen. > Es sei den der Debug-Mode lässt sich trotzdem irgendwie sinvoll > nutzen... Ich habe die HEX Datei mal dem Disassembler gegeben und die Ausgabe etwas kommentiert (s.Anhang): Es gibt da wohl doch so einiges, was nicht im Datenblatt steht. So wie ich das verstanden habe wird aber der PIC16F505-ICD eingesetzt. Dort scheint es eine "hidden" RAM Page zu geben. Auch hat das OSCAL-Register andere Funktionen (s.Kommentare). Ich werde das aber mal am 509 ausprobieren. Würde einiges einfacher machen ;-) Walter.
Den Code habe ich mir gestern abend auch reingezogen. Ist ja hochinteressant. Sie verwenden die undokumentierte Bank5, dort scheinen mehrere Register (auch die unteren, z.B. ) andere Funktionen zu haben. Der PIC16F505-ICD hat 20 Pins. Es gibt einen PIC16F506, der der große Bruder des PIC12F510 ist. In DS80190G wird beschrieben: 2. Module: PIC12F509 debugging with ICD2 (PIC16F505-ICD silicon) – Invalid FSR Power-Up Initialization The FSR on the PIC16F505-ICD debugger silicon initializes to an invalid state. When using the ICD to debug software with the PIC16F505-ICD, bit 5 in the FSR register must be manually cleared to ‘0’ prior to saving data in user RAM space. The power-up default is ‘1’, which causes the device to Access Bank 1. The power-up defaults are correct on the non-ICD version of the PIC12F509 devices. Work around: Add the following line of code to the top of your program; BCF FSR,5 ;set bank pointers to bank 0 This will have no effect on non-ICD devices, but will correct for the initialization errata on -ICD devices. Es ist offensichtlich ein anderes Chip. Mal schauen, ob es mehr Infos dazu gibt. Mit Euch ist es einfach tolles Teamwork. > Auch läßt sich ein laufendes Programm anhalten (/MCLR VCC -> VPP), > man kann das die SW im HF ausführen und durch absenken > /MCLR VPP -> VCC die "normale" SW fortsetzen. Weiß nicht, ich habe den Eindruck, beim Anheben der Vpp wird der PC auf 3FF gesetzt. Dann kann man den PC ändern und beim Absenken von Vpp wird das Programm vom aktuellen PC ausgeführt. Nur eine Vermutung, noch nicht ausprobiert.
Hallo eProfi, so wie ich das bisher ausprobiert habe kann man /MCLR anheben, dann "steht" die SW, wenn man /MCLR wieder auf Vcc absenkt läuft die SW weiter. Während /MCLR = Vpp steht der ProgramCounter (PC) auf "virtuell" 0x7FF (real: config word). Dann kann man mit dem "inc pc" Befehl (s.ICSP Doku) den PC Schrittweise vorwärts bewegen (Wrap around bei 0x7FF). Mit dem nicht dokumentierten Befehl (oder was auch immer das für ein Effekt ist) wird die SW ab der Position des PC ausgeführt (auch > 0x3FF). Wird während dessen (also während die SW läuft) /MCLR wieder auf VCC abgesenkt wird quasi sofort die "User-SW" an der Stelle fortgesetzt, wo sie vorher unterbrochen wurde. Daher gehe ich davon aus, bei /MCLR = Vpp ein Interrupt-ähnlicher Mechanismus ausgeführt wird, wobei der PC in irgendeiner Form gesichert wird. Ob dabei der "User-Stack" verwendet wird, muß ich noch herausfinden (s.oben). Walter.
Ich vermute, das der User-Stack nicht berührt wird. Anders würde es einfach dann so sein, das eine Ebene des Stacks nicht mehr in einem User-Programm real nutzbar wäre - zumindest nicht wenn ein Programm debugfähig sein soll. Sicherlich werden es Schattenregister sein.
eProfi schrieb: > Mit Euch ist es einfach tolles Teamwork. Es geht runter wie Holundersirup. Will jemand einen haben?
Abdul: Könnte es nicht sogar sein, dass es einen eigenen Debug-Stack gibt? In diesem Assemblercode sehe ich mehrere CALL und RETLW. Wenn man das wirklich alles auf dem normalen Stack machen würde, wäre der doch eigentlich unbenutzbar, oder?
Vermute ich. Schrieb ich doch gerade.
Ja das habe ich auch gelesen. Aber du hast ja geschrieben:
> Anders würde es einfach dann so sein, das eine Ebene des Stacks nicht mehr in
einem User-Programm real nutzbar wäre
Darum habe ich geschrieben, dass ich denke, dass der Debugstack *mehr
als eine Ebene* umfassen muss und vermutlich so groß ist wie der "echte"
Stack. Denn im Debugprogramm kommen ja mehrere CALL, RETLW usw. vor.
Ah so Johannes. Kann sein. Walter kann das ja prüfen.
Danke für den Tip mit dem 0x00F. Hab ich probiert - tut sich aber nix. Ich habe anscheinend grundsätzlich geirrt, was den "Interrupt" angeht. So wie ich das jetzt sehe wird nach jeder Änderung von /MCLR eine Art Reset, zumindest des Program Counters ausgeführt. Wenn ich /MCLR auf VPP anhebe steht der PC auf 0x7FF, wenn ich ihn wieder auf Vcc absenke auf 0x3FF. Mir ist es aber gelungen, "im Betrieb" den Inhalt von 0x33 (WDT counter) auf 1 zu setzen, so dass beim nächsten WDT Reset auf 0 heruntergezählt wird und der PIC ein Telegram decodiert. Damit ist die Zwangspause von 15*2,3s Beseitig. Ich habe momentan noch ein paar Probleme, das Telegram sauber reinzuschreiben (ein Clock geht anscheinend verloren), aber das bekomme ich noch in den Griff. Ich werde den RAM-Monitor so erweitern, dass das W-Register im Speicher abgelegt wird, das gibt noch ein bisschen mehr Info. Ich hab den aktuellen Stand mal angehängt - vielleicht hat ja jemand eine Idee Walter.
Hab das Datenblatt nochmal durchforstet: Es gibt nur 2 Stacklevel. Mehr gibts ned, wenn man trotzdem nochmal CALL macht, dann läuft der Stack über. Hab mir deinen Code mal angesehen. Ein paar Fragen hab ich noch: Der Code kommt also in den reserved-Flash rein, oder? Also das restliche Programm bleibt unberührt? Evtl. könnte das für Thomas (der mit der dcf-77-decoder Seite) praktisch sein, wenn die Befehle schneller durchlaufen. Ich sehe, dass du das W-Arbeitsregister auf 0x33 sicherst nachdem der WDTimer runtergesetzt wurde. Gute Idee! :-) Auch das Statusregister wäre praktisch wenn mans sichern würde, es wird oft Carry oder so benutzt. Man könnte es z.B. nach 0x01 schreiben, das ist nur der Timerstand, sofern der nicht verwendet wird kann man dessen Zähler als Speicherersatz missbrauchen ;-) Man könnte aber auch den Timer selbst verwenden um mit ihm die Clocks zu zählen. Egal wann man anhält, man wüsste immer der wievielte Befehl es gerade war. Der Timer geht zwar nur bis 255, aber das macht gar nichts, nachdem der Jitter doch nicht SO groß ist. Falls der Timer nicht benutzbar ist, könnte man immer noch die Versorgungsspannung verwenden um den Takt zu rekonstruieren. Ich mache diese Tage ein paar Versuche aber warte noch auf die OpAmps zur Auswertung.
An der Clock-Erkennung am Versorgungsstrom ist bereits jemand anderes dran. Eventuell meldet er sich ja. Benötigt der PIC egal für welchen Befehl, immer genau einen Takt? Kennt er auch keine Extrazyklen wenn z.B. der PC bestimmte Stellen überschreitet? Gibt solche CPUs!
Abdul: Ja ich beschäftige mich zurzeit mit der Clock-Rückgewinnung, hatte ja meine Bilder am 7.6. gepostet, eProfi arbeitet auch schon seit etwa 8.6. dran. Unsere Ansätze sind ähnlich aber nicht ganz gleich. Soweit ich verstanden habe versucht es er mit einem guten ADC hinzubekommen (sofern die Bauteilnummer stimmt). Ich versuchs mit OpAmp und Komparator. Beides kann zum Ziel führen, es schadet nicht wenn 2 dran arbeiten ;-) Der PIC läuft intern mit 4MHz, er braucht aber für nen normalen Befehl 4 Clockcycles. Also kommen hernach ca. 1 MHz raus mit denen er effektiv arbeitet. Alle Befehle brauchen 4 bzw. 1 Takt, alle Sprungbefehle RETLW, GOTO und CALL benötigen 8 bzw. 2 Takte.
Hallo zusammen, ich lese auch schon eine Weile mit. Allerdings habe ich etwas den Überblick verloren. Ich hatte gerade folgende Idee bezüglich dem RAM-Monitor. Ich sehe, dass wohl ab Adresse 0x0e angefangen wird auszulesen. Könnte es nicht sein, dass evtl. in einem ungenutzen Config-Register (evtl. Timer0 oder andere) auch Werte "versteckt" gespeichert werden? Falls Timer0 nicht läuft könnte man ja da evtl. auch Werte abspeichern (Ich kenne PICs nicht, aber vielleicht funktioniert das ja). Nicht dass ihr da evtl. was überseht. Falls mein Beitrag totaler Mist ist, einfach ignorieren. Grüße Mathias
Hallo MPS, danke für den Hinweis. Beim PIC sind Betriebregister an den Plätzen 1-6. Ab Adresse 7 fangen die gerneral purpose Register an. Beim Auslesen wird im Prinip jedes Register eingeschlossen. Folgende Register werden aber geändert: Adresse Funktion Grund - W (Akku) wird im Betrieb überschrieben 0 INDF nicht physikalisch implementiert 1 Timer wird für den 8-Bit Counter verwendet 2 PLC zeigt auf das Ausleseprogramm 3 STATUS diverse Flags werden geändert 4 FSR wird zum Auslesen als Pointer gebraucht 6 GPIO Kommunikation nach aussen Ich arbeite aber nach einer neuen Version, bei der ich wahlweise vor dem Auslsen die Register 1-6 sichere (z.B. 0x30+) Das Problem beim PIC ist, dass bei jedem Baustein ca.40 Worte (=Befehle) noch dazugeschrieben werden können. Dann ist Feierabend, da sich der Bereich (soweit ich weiss) nicht seperat löschen lässt. Also muß ich das Ding recht klein und flexiebel gestalten. So kann man ein Eingangsmuster 2x "durchsteppen", einmal mit Register 0-6 gesichert, beim 2. Mal nicht und danach die Ergebnisse zusammensetzen. Walter.
Walter Freywald schrieb: > So kann man ein Eingangsmuster 2x "durchsteppen", einmal mit Register > 0-6 gesichert, beim 2. Mal nicht und danach die Ergebnisse > zusammensetzen. Ah, das wollte ich sowieso mal erfragen: Sind Deiner Erfahrung nach bei identischen Daten die resultierenden Dumps identisch? D.h. der Ablauf hat keine wie auch immer geartete Zufallskomponente? (mal abgesehen von dem Jitter bei längerer Laufzeit). Falls dem so ist, könnte man evtl. dem Jitter begegnen, indem man einfach ein oversampling macht. Stellst Du vor Neustart des Programms einen Default-Zustand des RAMs her? Damit man auch mitkriegt, wenn vor der Verarbeitung der Daten Ram-Bereiche mit statischen Daten initialisiert werden... Viele Grüße, Simon
Hallo Simon, soweit ich das gesehen habe kommen immer die gleichen Daten heraus. Wie gesagt, der Speicher für zusätzliche SW ist sehr knapp bemessen. Ich würde am liebsten das RAM aus definierte Werte setzen. Momentan schiebe ich zuerst ein "0" Telegramm ein (80 x0). Damit sind dann schon mal die Adressen 0x16-0x1F und 0x36-0x3F auf Null und man kann prima das Reinschieben und Umkopieren beobachten. 0x33 ist wie gesagt der WDT Counter und zählt von 0x0F aus 0x00 herunter. Bleiben momentan noch 0x07-0x0F, 0x10-0x15 und 0x30-0x35. Das Problem beim PIC ist, dass der Bereich 0x00-0x0F nach 0x20-0x2F gepiegelt wird. Also kann ich nicht einfach bei 0x07 anfangen zu Nullen, bis ich bei 0x3F bin (da würde ich mit bei in 0x23 den PCL überschreiben) sondern müsste ein Fenster einbauen (wenn Adresse == 0x20 dann Adresse = 0x30) Der Code könnte etwa so aussehen: movlw .7 movwf FSR clr_loop: clrf INDF incf FSR,F btfsc FSR,5 goto clr_loop bsf FSR,4 clr2_loop: clrf INDF incf FSR,F btfss FSR,5 goto clr2_loop sleep Das sind schon wieder 12 Worte, wird eng. Walter.
Vielleicht kann man es verkleinern, wenn der RAM-Monitor selbst nichts mehr macht außer Befehle von außen zu übernehmen und auszuführen, so daß extern ganze Sequenzen als Batch-Datei vordefiniert werden können. Eventuell könnte man die Daten auch über ausgesuchte offizielle Meteo-Pakete einschleusen, um die serielle Kommunikation nicht auch noch schreiben zu müssen. Es gibt ja genug Meteo-Pakete. Da wirds sicherlich alle 256 Zustände in einem Byte geben. Muß man nur raussuchen. Erst wird das 'manipulierte' Paket reingebracht, dann der gewünschte zu untersuchende Meteo-Paket.
Hi, Abdul K. schrieb: > Vielleicht kann man es verkleinern, wenn der RAM-Monitor selbst nichts > mehr macht außer Befehle von außen zu übernehmen und auszuführen, so daß > extern ganze Sequenzen als Batch-Datei vordefiniert werden können. Mal von einem stillen Mitleser: Nein, das funktioniert leider mit den kleinen Pics nicht da Befehle ja nur aus dem Programmspeicher abgearbeitet werden können. Also müsste man die Empfangenen befehle erst in den Programmflash ablegen und dann dahin springen. Mit den Großen PICs geht das, die älteren kleinen wie die 12x509 können das aber nicht. (Wobei das auch wieder einiges an Programmcode für den "Bootloader" -nicht anderes währe das ja- ist) Natürlich könnte man etwas "ähnliches" auchbei den kleinen PICs construieren, eine aufgemotzte "switch case" Geschichte. Aber ob das -selbst als assembler Programm- überhaupt in den kompletten Programmflash passen würde? Ganz sicher -leider- nicht in den kleinen Bereich. Gruß Carsten BTW: ICh finde das Projekt interessant, habe aber kein "original" IC und werde mir -da die Zeit sowieso gerade mehr als Knapp bemessen ist- auch jetzt erst mal keine Uhr zum schlachten zulegen. Kann mir aber mal jemand die Aussenbeschaltung des PICs verraten, und den Grundsätzlichen "Ablauf", dann würde ich als "spielerei" zumindest ein paar Grundsätzliche Dinge zur "Ablenkung und Entspannung" probieren... So wie Taktrückgewinnung oder ganz "fantastisch" gedacht bei funktionierender Taktrückgewnnung eine automatisierte Ausleseschaltung mit einem zweiten größeren µC der selbständig erst mal einen Befehl, dann zwei Befehle, dann Drei Befehle laufen lässt bevor er ausliest und die Daten dann gesammelt zur Verfügung stellt... Testen kann man das ja mit einem fast beliebigen Grundprogramm, muss nur das obige leseprogramm einspielen... (509er Pics habe ich übrigends da...)
wisst ihr zufällig wieviel vom flash des pic belegt ist? evtl. hätte man ja am ende des flashs im normalen bereich noch ein bisschen platz... nen indirect call auf eine programmadresse klappt nicht, oder? die adresse muss fest implementiert werden? oder kann man einfach den Programcounter beschreiben? nochmal eine frage: wird der interne timer bereits benutzt? werden ALLE ramadressen benutzt? 0x30 oder so ändert sich erstmal nicht. könntest du bitte nen ramdump eines gültigen pakets kurz vor der ausgabe posten?
Nein, ich meinte keinen Code laden! Sondern nur Befehle wie READ RAM Address, WRITE RAM Address etc. Wir wollen ja nur einen Monitor! Zum extern mitlaufenden Taktgenerator kann ich die Erfahrung mit Injection Locking Oscillatoren beisteuern. Falls das jemanden nützt. Funzt simpler als eine PLL und ist genauso gut. Läuft bei mir in LTspice und in Hardware recht zuverlässig.
johannes o. schrieb: > wisst ihr zufällig wieviel vom flash des pic belegt ist? evtl. hätte man > ja am ende des flashs im normalen bereich noch ein bisschen platz... > nen indirect call auf eine programmadresse klappt nicht, oder? die > adresse muss fest implementiert werden? oder kann man einfach den > Programcounter beschreiben? Soweit ich das verstanden habe, muß man ins Blaue schreiben. Weiß also nicht, ob man notwendigen Code überschreibt (was man auch ausnützen könnte). Kann man den PIC überhaupt in kleinen Blöcken löschen bzw. Befehlsweise beschreiben? Geht der Versuch ins Blaue schief, benötigt man eine neue Uhr. Da freut sich Meteotime über die vielen Bastler. > > nochmal eine frage: wird der interne timer bereits benutzt? > werden ALLE ramadressen benutzt? 0x30 oder so ändert sich erstmal nicht. > könntest du bitte nen ramdump eines gültigen pakets kurz vor der ausgabe > posten? Laß doch den Zähler extern mitlaufen. Ist weniger Aufwand. Zumindest falls es intern nicht klappen sollte.
Ich dachte der RAM-Monitor liegt in diesem "High-Flash"? Da sollen einige Byte sein die man beschreiben kann. Hab dazu auf einer Seite auch schon Infos gefunden, dieser Bereich wird von Debuggern benutzt (wurde hier glaub ich auch schonmal geschrieben). Evtl. "kennt" ja der Debugger den Befehl nur diesen Bereich zu löschen? Ich habs Datenblatt auch nochmal durchgesehen und offenbar lassen sich indirect gotos oder sowas ähnliches ausführen. PCL und noch ein paar andere Bits lassen sich nämlich schreiben. Ich könnte mir vorstellen, dass im normalen Flash noch durchaus einiges frei ist. Könnte man einfach indirekt Calls drauf machen und schauen was passiert. Das das Ding zu 100% benutzt ist glaub ich kaum... Ganz interessant: Dieses Auslesen des ersten Speicherbereichs der sich nicht durch Codeprotection schützen lässt, scheint offenbar beabsichtigt zu sein. Das Datenblatt(!!!) meint, dass man dies machen kann! Ich kauf mir jetzt dann nen PIC-Programmer und versuch auch mal mitzubasteln ;-)
Der untere Bereich ist sicher für sowas wie Seriennummern gedacht. Ist üblich.
Ja wird vermutlich so sein! Entweder die Leute haben das Datenblatt nicht richtig gelesen, oder ihnen ist der Flash knapp geworden ;-) @all: Ist in folgender Station ein PIC12F509 enthalten? http://www.amazon.de/TFA-35-1080-Funkwetterstation-Meteotronic-Start/dp/B000WZYR84/ref=sr_1_1?ie=UTF8&s=garden&qid=1307656282&sr=8-1 Laut Wiki-Artikel hier: ja. Aber ich hätte gerne noch eine Bestätigung. Den Rest zum PIC-Programmieren/basteln kaufe ich mir gerade noch. Kann man den RAM-Monitor mit dem normalen Programmer aufspielen oder braucht man da irgendeine spezielle Version? Ich komm eher aus der AVR-Ecke, daher hab ich noch keine Erfahrung mit PICs, aber Erfahrung mit Mikrocontrollern und insbesondere mit Assembler ist vorhanden! Hier gibts noch genauere Infos zur Flashaufteilung: http://ww1.microchip.com/downloads/en/DeviceDoc/41227E.pdf 0x405 bis 0x43F (59 Byte) sind also offenbar "frei" für den RAM-Monitor? Bisher sind erst knapp 40 Byte belegt wenn ich mich nicht verzählt habe. Wird der PIC an sich "gestört" wenn man ihn umprogrammiert? Also würde die Wetterstation noch laufen auch mit RAM-Monitor im Flash (wenn ich ihn wieder zurücklöte?)? Schon oder? (jetzt will ich mal tatkräftig mithelfen anstatt nur immer datenblätter zu lesen ;-) )
Wetterstation FTA: sieht aus wie meine, und da ist einer drin. Schau doch mal hier: http://www.amazon.de/Meteotronic-Crosse-Wetterinfo-Center-TFA/dp/B002VQLOHY/ref=sr_1_2?ie=UTF8&qid=1307697012&sr=8-2 die geht unter 10 Euro her ;-) Ich glaube, das Flash kannst Du nicht mit einem Standart Programmer beschreiben, evtl. den PIC16F505 einstellen. Ich habe mir was selber gebastelt, daher kann ich das nicht genau sagen. Der Baustein läuft danach ohne Probleme, solange Du nur im Bereich 0x405-0x43F wütest ;-) Das Flash unter der Codeprotection (0x40-0x3FE) lässt sich nicht beschreiben, das habe ich schon versucht. Ich habe bisher noch keine Möglichkeit gefunden, den Bereich 0x405+ seperat zu löschen. Also zum experimentieren besser einen "standart" PIC verwenden... Walter.
Hi, ICh habe gestern NAcht aus Langeweile doch mal ein paar Versuche gemacht hinsichtlich des Timings des Auslesens... Erst einmal "Proof of Concept" Leider stellte sich heraus das die vermeintlichen drei 12F509 in meinem Bestand 12C509 waren die ich jetzt nicht für grundlegenste Versuche opfern wollte, denn es sind ja nur OTP bausteine (1-1 Ersatzteile für eine Zertifizierte Schaltung... Müsste also auf jeden Fall wieder C nachbesorgen und nach drei Versuchen wäre eh schluss) Also bin ich für ersttests auf 16F628 umgeschwenkt. Ich habe daraufhin ein Programm geschrieben wo nur einZähler hochgezählt wird, Die Ausgabe des Zählständs Binär habe ich über PortB mittels LED realisisert. Natürlich abschaltbar! Versuch war jetzt dahingehend ob es mir möglich ist aus dem Taktsignal eine Zeitreferenz zuückzugewinnen um den Pic gezielt anhalten zu können. Da meine obige Anfrage zur Aussenbeschaltung leider nicht beantwortet wurde bin ich jetzt von einem internen RC Takt ausgegangen, das Anzapfen eines mittels Aussenbeschaltung (Oszillator, RC Glied oder Quarz) erzeugten Taktes wäre je eine absolute Kleinigkeit Versuche 1. (Ohne AUSGABE, nur Internes REchnen): Taktrückgewinnung über Ub gelingt mir nicht ordentlich, zumindest nicht solange das "sonstige" Elektronische Gerät in meinem Zimmer läuft. (Von der Leuchtstoffröhre über PC über ...) Viel zu viele Störungen auf dem Signal. Das abschalten der Leuchtstoffröhre brachte erhebliche Verbesserungen (erwartet) aber immer noch ein sehr gestörtes Signal, bei verschiedenen "Messwiderständen". -> Versuch abgebrochen um bessere Wege zu finden, mit dem hintergedanken das notfalls in "geschirmter" Umgebung zu wiederholen. Versuch 2. Taktrückgewinnung durch EMV des µC. An den Nichtgenutzen IOs des Pics konnte ich Nadelimpulse mit einer Wiederholfreqeunz von ca. 4,2Mhz ausmachen. Selbst mit nur auf dem Harz gedrücktem Taskopf waren die Wahrnehmbar. Ein Versuch mit kleiner Antenne (2cm Draht) auf dem Pic, Abschirmung dann direkt an Masse beim Pic und zuführung über RG174 zum Skope brachte Peaks von ca. 5mV über Rauschen. Ich gehe davon aus das dies direkt mit dem internen Oszillator zusammenhängt. Das Aktivieren der Ausgänge brachte kleinere Störpeaks mit deutlich niederer Frequenz. Erstaunlicherweise geringer als erwartet. ICh habe dann eine Kette aus drei Bandbässen mit einer Mittenfrequenz von 4,3 Mhz aufgebaut, die Güte ist nicht die beste, war ein Schnellschuss... Diese Kette habe ich dann vor einem HF Messverstärker gehangen, noch ein Bandpass dahinter und dann einen Video OP als Komparator. Der Testweise angeschlossene Spekki wie auch der Frequenzzähler lieferten relativ Kosntante Ergebnisse, ein sehr langsames Wandern anstelle schneller Sprünge deuteten darauf hin das ich tatsächlich recht ganu das Oszillatorsignal direkt messen kann. Dann habe ich das Signal duch einen mit simpler Logik realisiserten Teiler :4 herausgeführt. Mit dem Demoboard welches auch beim PicKit debug express vorhanden ist (Pic 18F45K50) habe ich dann kleines Programm entwickelt das abhängig von der Einstellung von 8 Dip schaltern an seinen Ports diese Impulse zälht und jeweils nach erreichen der Voreingestellten Impulszahl (=4x Takt) den anderen PIC anhält, 5sek Warten, neu startet, wieder zählt usw... in gut 90% der Fälle hier der PIC jeweil pro Einstellung beim selben Zählwert an. Niemals war es aber mehr als zwei Zählwerte entfernt. Das ist schon ein recht gutes Ergebniss. Die interpretation der Zählwerte erfolgte jetzt aber alleine durch die LEDs, es ist natürlich noch zu bedenken das daher zwei Zählwerte Differenz vier BEfehlszyklen sind. Ausgeelsen habe ich nichts, es gin mir nur ums Punktgenaue stoppen. Die Idee währe jetzt, dieses Ergebniss durch bessere Filterung noch zu verbessern und den "Steuerpic" soweit "aufzumotzen das er sowohl das Eintakten der Beferhlskette übernimmt und dann selbstständig einfach mal eine Zeitlang werkelt, den Pic dann nach einem Befehlzyklus, nach Zwei Befehlszyklen usw.Anhält, den RAM Monitor Startet, diesen Auslist usw. Am besten mindestens drei Mal pro Taktzahl und dann per Mehrheitseintsheidung eine Tabelle ausgibt. Natürlich alles in VErbindung mit einem PC Programm. (Z.B. USB Pic, String wird per USB eingestellt, die Daten kommen per USB zum REchner und das PC Programm übernimmt die WEiterverarbeitung (z.B. Mehrheitsentscheidung) Natürlich wird ein gesamtdurchlauf so eine Menge Zeit dauern, aber das könnte ja unbeobachtet laufen. Evtl. findet man durhc Stichproben bzw. ander Zählalgorythmen auch lange Zyklen wo sich nichts ändert oder wirklichnur ein Register runtergezählt wird und diese kann man dann ignorieren. Klingt erst einmal vieleicht sonderlich kompliziert, ist es meiner Ansciht aber überhaupt nicht. Es ist allerdings eine Fleissarbeit das zu schreiben und es gibt doch einige Stolpersteine. Evtl. aber mal eine Anregung... ICh habe mir jetzt auch mal eine Uhr bestellt, komme vor Ende september aber nicht wirklich dazu soetwas zu realisiseren. Evtl. werde ich das dann aber mal in Anriff nehmen... Und auf jeden Fall muss man ja noch sagen das ich diesen Test mit einem 1F628 gemacht habe, nicht mit einem 12F509. Es ist also nicht gesichert das die Taktrückgewinnung auf diese weise beim 509 genauso gut klappt Gruß Carsten
Ich habe eine Messung mit 50 Ohm Terminierung an VDD bekommen. Die sieht sehr gut aus! Weiß aber nicht, ob ich sie hier veröffentlichen darf. Also gehen tuts bestimmt!
Warum sollte die Veröffentlichung nicht erlaubt sein? Es ist ja allgemein bekannt, dass ein µC Impulsweise Strom zieht. @Carsten: Bei meinen Versuchen mit nem Atmega hatte ich auch ähnliche Probleme, dass die Rückgewinnung kaum geklappt hat. Mit einer Spule als Übertrager waren die Signale aber sehr gut! Evtl. kommst du auch so noch ein bisschen weiter? Da ich die Resonanzfrequenz der Spule erwischt hatte (oder nahe dran war?), hatte ich eine Spannung von ca. 700mV erhalten! (Muss aber auch anmerken, dass der Atmega auch ein bisschen mehr braucht als ein PIC und man das nicht so 1:1 übertragen darf). Außerdem würde damit dann der Gleichanteil wegfallen, was deutlich angenehmer beim Messen ist. Hoffentlich bekomme ich meinen Programmer bald und die Wetterstation müsste auch sehr bald ankommen. Hab mir von LT auch noch einen schnellen OpAmp und einen Komparator geholt, mal schaun ob sich da was machen lässt!
Bild: Weil der der es gemessen hatte und mir schickte, darum bat es nicht zu tun! Ein Übertrager ist ne gute Sache. Auf der Sekundärseite brauchste nur einen 74HC14 und nen Spannungsteiler. Wenn das Windungsverhältnis nicht ausreicht, dann bau vor den HC14 noch ein oder zwei 74HCU04 Gatter mit Gegenkopplung 10K//18p. Gehen auch schnellere Varianten LCX usw. Eine HCU04 Stufe bringt einen Spannungsverstärkung von ca. 10-15. Das geht genauso gut wie der schweineteure LTC-Komparator. Dann haste aber keine PLL, die als Filter wirken würde. Da würde ich dann meinen Synchronous Oscillator als Filter vorschlagen. Der kann gleichzeitig auch als Multiplizierer dienen, wenn man auf eine Subharmonische locken muß.
Zum Bild: Ok das ist dann natürlich ein anderer Grund und verständlich! Zum Übertrager: Ich probier die nächsten Tage mal nen Übertrager aus einer alten Netzwerkkarte aus, evtl. geht der noch besser. Denn bei höheren Frequenzen (der PIC scheint ja mit 4 MHz zu laufen mit einem Teiler auf 1MHz), hatte ich noch keinen solchen Erfolg. Das mit der PLL usw. muss ich mir noch genauer ansehen da hab ich noch nicht so die Erfahrung...
Ist es möglich ein Update über das Feature zu bekommen. Ist ein Ausführen des Codes nach dem Debuggen möglich ? Wie sieht es mit single step aus ? mit hilfe von pcl sowie pclath Wie sieht der aktuelle debug-code aus.
Ursprünglich ging es hier um die Erkenntnis wie MeteoTime funzt. Mittlerweile scheinen aber diverse Leute das für eigene Zwecke nutzen zu wollen: Nämlich einer Anleitung wie man diesen oder möglichst viele PIC-Typen knackt. Ich weiß nicht, ob das im allgemeinen Interesse 'gut' ist.
Ein debugger wo ich den Pic anhalten kann und Funktionen aufrufen kann finde ich schon sinnvoll wie auch das Ram-dump. Weiters wäre es interessant zu wissen was es mit dem Ausführen des Codes mit sich hat. Ob nur die Speicherstelle 0x4 funktioniert wie in den ICD specs beschrieben und damit ein Opcode 0xf reicht den Pic sicher zu machen oder nicht. Was auch nicht ohne wäre die zusätzliche Ram. Ich weiß, der DIE von 16f505 sowie 12f508/9 ist derserlbe, nur daß gewisse Funktionen durch Fuses abgeschalten sind. Dasselbe ist auch mit 10f typen sehr interessant. Fazit: Damit lässt sich ein ICD realisieren welcher keinen Flash Speicher braucht und der sehr resourcenschonend ist. Auch war mir nicht bewusst daß der Initcode im Flash war und frei Programmierbar, ich nahm fälschlicherweise an daß sich dieser im Rom des uC befand.
Es sind drei Besonderheiten, die ein erweitertes Debugging möglich machen: 1. Im DEBUG-Modus, d.h. VPP=13V, kann man den ProgramCounter auf jeden Wert setzen, den man möchte, auch auf einen Wert >=0x2000, den sogenannten Hi-Flash, der im normalen Modus nicht zugänglich ist. Dies ist mit den dokumentierten ICSD-Befehlen möglich und auch gewollt, da man so ID und Revision des Chips auslesen kann und eigene UserIDs einprogrammieren kann. 2. Es gibt mehrere undokumentierte ICSD-Befehle, die ein Ausführen des Codes an der gerade im ProgramCounter befindlichen Stelle bewirken. Bis jetzt ist ein echter Single-Step Befehl noch nicht bekannt, d.h. der Code läuft los, hält aber nicht selbständig wieder an. 3. Man kann zwischen DEBUG-Mode und normalem Mode wechseln, ohne einen RESET auszulösen, indem man VPP nicht auf GND zieht, sondern nur zwischen 5V und 13V hin und her wechselt. Ein Wechsel vom normalen Mode in den DEBUG-Mode hält den Prozessor an. Wenn jetzt noch Platz ist im Hi-Flash (ungefähr 40 unbeschriebene Bytes im Auslieferungszustand), kann man sich die Möglichkeiten ausmalen. Zur Zeit beste Chance zur Absicherung seines eigenen Codes ist es, den Hi-Flash-Bereich auszunullen, damit dort keine neuen Befehle einprogrammiert werden können.
Meine 12F509 sind angekommen. Gleich ausprobiert und das Debug-Register ist freigeschaltet. Also Single Step ist auch möglich.
Hab auch schonmal mit dem OSCCAL rumprobiert. Konnte aber nur den Takt verändern mit dem er läuft. Oder gibts da nen speziellen Wert mit dem man single step machen kann?
Es geht nur nach einem POR als Reset, ansonsten muß man den Debugmodus im Config setzen und dann ist ein Pin weg.
@guest: super, danke für die Info. Ich hatte mir schon mal den Debug Code für ICD (Beitrag #2214003) disassembliert. Dabei wurde anscheinend mit Hilfe des OSCAL Registers unter anderem die Richtung des ICSP_DAT Pins umgeschaltet. Ich hatte angenommen dieses Verhalten gelte nur für den "Debug"-Chips und habe da nicht weiter rumprobiert. Dort scheint es auch einen "versteckten" RAM-Bereich zu geben. Würde das ganze noch etwa mehr vereinfachen. Muß ich mir nochmal anschauen. Walter.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.