Forum: Mikrocontroller und Digitale Elektronik ATmega48 Security Bit Port Problem


von Sascha (Gast)


Lesenswert?

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

von spess53 (Gast)


Lesenswert?

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

von sascha (Gast)


Lesenswert?

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.

von Εrnst B. (ernst)


Lesenswert?

Mal versucht das Brennen und Locken zu trennen?
Also: Zuerst Programm rein, testen, und wenns passt NUR noch die 
Lockbits dazu?

von spess53 (Gast)


Lesenswert?

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

von Sascha (Gast)


Lesenswert?

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

von Peter D. (peda)


Lesenswert?

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

von Sascha (Gast)


Lesenswert?

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

von holger (Gast)


Lesenswert?

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

von Peter D. (peda)


Lesenswert?

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

von Sascha (Gast)


Lesenswert?

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
Noch kein Account? Hier anmelden.