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.
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
