Hallo ich habe ein Problem mit dem ATmega48, wenn ich die Fuse-Bits setze damit er gegen das Auslesen geschützt ist funktioniert auch meine Software nicht mehr, da ich die Portpins PB3,PB4 und PB5 benutze, allerdings nur im I/O Mode.(PB3,PB4 und PB5 werden auch fürs SPI Programmieren benutzt.) Setze ich keine Fuse-Bits gegen das Auslesen des Chips, dann funktionieren die Port-Pins PB3,PB4 und PB5 ohne Probleme ?!? Laut Datenblatt kann ich dem nichts entnehmen. Wer kann mir weiterhelfen ? Hat schon jemand das gleiche Problem gehabt ? Kann ich per Software etwas Um/Abschalten ? Gruß Sascha
Hi >Hallo ich habe ein Problem mit dem ATmega48, wenn ich die Fuse-Bits >setze damit er gegen das Auslesen geschützt ist funktioniert auch meine... Es gibt keine Fuse-Bits, die gegen Auslesen schützen. Und die Security-bits haben keinen Einfluss auf die Ports. Dein Problem liegt woanders. MfG Spess
Hallo, Danke für die schnelle Antwort Spess53, es gibt sehr wohl sogenannte Lock-Bits, die man auch setzen kann um den Chip vor dem Auslesen zu schützen. Das funktioniert auch ganz gut, haben wir soweit überprüft weil wir auch einen Parallel Programmer haben der im HV-Mode arbeitet. Das die Lock-Bits nichts mit den Port-Pins zu tun haben sollen wäre schön. Also an meiner Software kann ich mir im moment keinen Fehler vorstellen.
Mal versucht das Brennen und Locken zu trennen? Also: Zuerst Programm rein, testen, und wenns passt NUR noch die Lockbits dazu?
Hi >Danke für die schnelle Antwort Spess53, es gibt sehr wohl sogenannte >Lock-Bits, die man auch setzen kann um den Chip vor dem Auslesen zu >schützen. Gut. Habe ich nach 13 Jahren AVR-Programmiererei wieder etwas gelernt. >Das die Lock-Bits nichts mit den Port-Pins zu tun haben sollen wäre >schön. Das ist so. >Also an meiner Software kann ich mir im moment keinen Fehler vorstellen. Das rede ich mir auch immer ein. MfG Spess
Hallo Ernst, ja das habe ich auch schon probiert und genau dann, wenn der Ausleseschutz kommt geht es nicht mehr. Ich habe die Software über DebugWire entwickelt (was ja sagenhaft geht) und wenn ich dann die Chips über SPI flashe (mein Tool ist der JTAGICE 2 von Atmel) gehts auch ohne Probleme, nur nicht mit dem Ausleseschutz. Ist ja ziemlich Intressant, aber irgendetwas muss sich ja wohl im Chip verändern. Nur waaaaas..... PS. die SPI und DW Schnittstelle zum umschalten ist manchmal auch echt nervig. Ich setze in Zukunft nur noch Chips mit eindeutiger Schnittstelle ein, also eine die immer present ist.ATXmega habe ich getestet und war begeistert. STM32 ist klasse gemacht und auch die anderen ARM7TDMI mit JTAG. Mein wohl größtes Problem des Atmega48 ist die Gehäuseform MLF32, da komme ich nicht so schnell mit Nadeln zum Kontaktieren hin. D.h. prallel programmieren fällt aus wenns schief leuft. Gruß Sascha
Also die Lock-Bits beeinflussen nicht die Programmausführung. Hast Du wirklich nur die Lockbits geschrieben und nicht auch die Fusebits? Es könnte vielleicht sein, daß sie das Debugwire abschalten und das kann durchaus Unterschiede bewirken. Z.B. sind die Stromsparmodies im Debug nicht aktiv. Debugwire aktiv bei gesetzten Lockbits wäre ziemlich unsinnig. Peter
So jetzt leuft mein Programm. Konnte den Fehler aber immer noch nicht richtig ausfindig machen. (zumindest nicht Gedanklich nachvollziehen.) Habe die WDT nochmals überprüft alles O.K. Habe den Takt überprüft O.K. Habe jetzt folgendes geändert: Das ich die Ports vorher als Eingang im DDRB Register setze vor ich die PINB Register lese. Anscheinend gaben die immer signal 0 zurück, obwohl der externe Zustand logisch 1 hatte. Und die Ports nach Reset als Eingänge sein müssten !?! Ohne Security Bits gings, da gab mir das PINB Register eine 1 zurück, mit Security wohl 0. ?!? Bei all solchen nicht eindeutig nachvollziehbaren Problemen sehe ich halt immer die Gefahr, das sowas einen wieder einholt wenn man in Serie geht. Habe jetzt aber schon 150 solcher CPUs mit der Software ohne Probleme am laufen. Gruß Sascha
>Ohne Security Bits gings, da gab mir das PINB Register eine 1 zurück, >mit Security wohl 0. ?!? Hat beides nichts miteinander zu tun. Ich hab schon Unmengen AVR lesegeschützt. Probleme mit den Pin Registern gab es da keine. >Bei all solchen nicht eindeutig nachvollziehbaren Problemen sehe ich >halt immer die Gefahr, das sowas einen wieder einholt wenn man in Serie >geht. Da kannst du von ausgehen das dir dieses Problem irgendwann unerwartet in den Hintern tritt. Du hast ein Softwareproblem oder ein Hardwareproblem. Wie sieht es mit Pullups am Pin aus?
Sascha schrieb: > Bei all solchen nicht eindeutig nachvollziehbaren Problemen sehe ich > halt immer die Gefahr, das sowas einen wieder einholt wenn man in Serie > geht. Das wird es wohl. Du kannst davon ausgehen, das die Eingänge funktionieren. Es wird mit Sicherheit ein Softwarefehler sein. Solche Fehlerbilder klingen danach, daß Du floatende Eingänge mit auswertest. Floatende Eingänge muß man immer ausmaskieren! Oftmals braucht man nicht den ganzen Port, sondern es interessiert nur ein Pin. Dann setzt man alle anderen Bits per AND auf 0, ehe man das Byte auswertet. Oder man nimmt gleich den SBIS/SBIC-Befehl. Floatende Eingänge können sich mit der Zeit auf einen anderen Pegel aufladen. Dadurch erklärt sich das unterschiedliche Verhalten nach dem Einschalten oder nach einem Reset per Debug. Peter
Hallo Holger und Peter, ich kann mit Sicherheit sagen, das ich kein Hardware Problem habe und auch keine Floating Pins, also Eingänge habe, da ich aus Prinzig immer an allen nichtbenutzten Eingängen Pullups aktiviere. Pullups sind da besser als ein statisches Signal, denn wenn man beim Messen mit der Messspitze abrutscht gleich einen Portpin geschaft hat. Ich habe an der erstem Programmstelle jetzt den Interrupt abgeschalten, dann Watchdog zurückgesetzt, Stack Initialisiert und dann meine Hardware initialisiere usw. Jedenfals kann ich den Fehler auch nicht mehr aufrufen. Hallo Peter, ich glaube wir sind uns schon vor ca. 6 Jahren (oder ist es auch schon länger her) aus dem 8052 Forum bekannt oder ?!? Man die Zeit vergeht und nichts bleibt hängen........ Habe früher Z80,68000,8051,M16C,M32C,AVR,ARM7 und jetzt auch noch Cortex M3 und morgen solls noch ein ARM9 werden so durchgemacht. Und alle dieser CPUs programmiere ich fast im Schlaf in Assembler. PS. ich will auf einem AT91SAM9293 ein eigenes Betriebssystem noch schreiben. (Da mir Windoof CE und Linux nicht genug embedded ist) Gruß Sascha
Bitte 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.