Brown Out

Neulings-Fragen zu Spannungs-Unterbrechungen

Pedro Veloceros
 
Avatar
 
Subject:

Brown Out

 · 
Posted: 31.01.2011 - 22:29  ·  #1
Hallo an das E-Lab-Forum,

es geht um eine Schaltung mit einem Tiny44. Diese Schaltung wird durch ein- / ausstecken eines Akku-Kabels in/außer Betrieb genommen. Dabei kommt es beim Inbetriebnehmen kurzzeitig zu ungewollten Programmzuständen.

Folgende für Euch sicher einfache Fragen treiben mich dazu um:
1. Ist "Brown Out" der richtige Ausdruck für den Spannungsabfall beim Abklemmen der Versorgungsspannung? Ist es dann richtig, einen "BOD"-Level zu setzen? Ich habe das so gemacht, allerdings ohne eine Verbesserung zu erzielen:
Code

Define_Fuses
  LockBits0 = [];
  FuseBits0 = [];
  FuseBits1 = [BODLEVEL0, BODLEVEL2];
  FuseBits2 = [];

2. Ist es für einen funktionierenden Brown Out erforderlich, schaltungstechnisch eine Kurzzeit-Spannungsversorgung bereitzuhalten. Wie setzt man das praktisch um?

Danke für Eure Hilfe
Pedro
Gunter
Administrator
Avatar
Gender:
Location: Frankfurt Main / Germany
Posts: 1697
Registered: 02 / 2003
Subject:

Re: Brown Out

 · 
Posted: 31.01.2011 - 23:54  ·  #2
Hi Pedro,

Du musst bei Define_Fuses die aktiven Fuses angeben, also
die Fuses die binär 0 sein sollen.
Deine BOD FuseBits1 sind aber xxxx x010 und das ist "reserved"!
Dein Absicht war wohl:
FuseBits1 = [BODLEVEL1]; // BOD Fuses = 101

BOD Level Fuses setzen ist schon OK (und beim Tiny44 hinreichend),
um den BOD zu aktivieren (der hat keine BODen-Fuse).
Eine Spannungsüberbrückung ist aus diesem Grund nicht notwendig.
Dem BOD ist "egal" woher die Spannung kommt.

Quote
Dabei kommt es beim Inbetriebnehmen kurzzeitig zu ungewollten Programmzuständen.

Wenn die Korrektur nicht hilft und machbar, würde ich direkt am Anfang ein
mDelay(100) ... mDelay(500) einfügen.
Bis dahin sollte dann die Versorgungsspannung stabil sein.

Gruß
Gunter
Pedro Veloceros
 
Avatar
 
Subject:

OK, so gehts

 · 
Posted: 01.02.2011 - 21:03  ·  #3
Hallo Gunther,

vielen Dank für deine schnelle und verständliche Erklärung. Ja, die FuseBits1 hatte ich verkehrt herum gesetzt. Hab ich korrigiert sowie den mdelay(500) am Anfang eingefügt - jetzt funktioniert es wohl.

Kleine Nebenfrage: sollte ich jetzt die FuseBits erkennen können im Programmer-Menü > Options > Programmer Options? Ich hätte hier beim Auslesen entsprechende Haken erwartet, sehe aber keine.

Danke nochmal und Gruß
Pedro
Attachments
Programmer Options
Filename: Clipboard.jpg
Filesize: 187.41 KB
Title: Programmer Options
Download counter: 143
rh
Administrator
Avatar
Gender:
Location: Germany
Age: 24
Homepage: e-lab.de
Posts: 5558
Registered: 03 / 2002
Subject:

Re: Brown Out

 · 
Posted: 01.02.2011 - 21:56  ·  #4
Hallo Pedro,

die linke "read" Spalte ist identisch mit der rechten "write" Spalte. Also ist doch alles ok.

rolf
Gunter
Administrator
Avatar
Gender:
Location: Frankfurt Main / Germany
Posts: 1697
Registered: 02 / 2003
Subject:

Re: Brown Out

 · 
Posted: 01.02.2011 - 23:25  ·  #5
Hi Pedro,

Rolf hat da wohl nicht nochmals den kompletten Thread gelesen
und Dein eigentliches Problem gar nicht gesehen.

Du musst bei existierenden Projekten

Define_Fuses
  Override_Fuses;
  LockBits0 ...

definieren!

Btw:
(nicht im Sinn von "RTFM" - als Hilfe zur Selbsthilfe gemeint)
das steht auch Alles in DocuCompiler.pdf:

4.6.8 DEFINE_FUSES
...
Alle Fuses sind low-active, d.h. wird ein Fuse Namen angegeben, z.B. "CKSEL1",
so wird dieses Bit auf NULL (low = aktiv) programmiert.
Nicht aufgezählte Fuses werden deshalb immer auf "1" (high = inaktiv) programmiert!
...
Bei der Neu-Erstellung eines Projekts werden diese Fuses automatisch in das ISPE-File
für den Programmer geschrieben.
Wenn das ISPE File schon existiert, wird es nicht mehr verändert.
Mit der Angabe "OverRide_Fuses" wird ein update in das ISPE File erzwungen.
OverRide_Fuses muss unmittelbar nach Define_Fuses stehen.


Gruß
Gunter

Nachtrag:
ein mDelay ganz am Anfang ist nie verkehrt!
Das soll aller angeschlossenen Peripherie genügend Zeit geben,
stabile Anfangsbedingungen zu erreichen bevor der 1. Zugriff erfolgt.
Pedro Veloceros
 
Avatar
 
Subject:

Override => wrong device

 · 
Posted: 05.02.2011 - 22:23  ·  #6
Hallo Gunther,

vielen Dank für Deinen wie immer fundierten und verständlichen Rat. Hab jetzt den override-Befehl eingefügt
Code

Define_Fuses
  Override_Fuses;
  LockBits0 = [];
  FuseBits0 = [];
  FuseBits1 = [BODLEVEL1]; // Binär 0 heißt: Bit gesetzt, hier also 0000 0101
  FuseBits2 = [];

Bedauerlicherweise erkennt jetzt der Programmer das Device nicht mehr (siehe Screenshot. Was habe ich falsch gemacht?

Gruß
Pedro
Attachments
Brown Out
Filename: Clipboard.jpg
Filesize: 192.13 KB
Title:
Download counter: 120
Gunter
Administrator
Avatar
Gender:
Location: Frankfurt Main / Germany
Posts: 1697
Registered: 02 / 2003
Subject:

Re: Brown Out

 · 
Posted: 05.02.2011 - 23:19  ·  #7
Hi Pedro,

Du hast nicht auf die CKSELx Fuses geachtet und diese jetzt auf "1111" programmiert!
FuseBits0 = [];
Der Tiny geht jetzt von einem Quartz/Resonator an XTAL1/XTAL2 aus und hat keinen Clock mehr.
Program Fuses programmiert natürlich immer ALLE Fuses!
Die müssen dann natürlich auch alle korrekt angegeben sein.

Wenn Du einen Quartz/Resonator oder einen externen Takt (Oszillator an CLKIN) anschliessen
kannst, ist der Tiny44 sicher wieder zu reaktivieren. Oder nimm gleich einen neuen.

Tipp:
zum "Basteln" besser das "Program Fuses" rausnehmen und nur für Änderungen aktivieren!
Und das erst nach doppelter Überprüfung.

Gruß
Gunter
Selected quotes for multi-quoting:   0

Registered users in this topic

Currently no registered users in this section

The statistic shows who was online during the last 5 minutes. Updated every 90 seconds.
MySQL Queries: 17 · Cache Hits: 15   114   129 · Page-Gen-Time: 0.028335s · Memory Usage: 2 MB · GZIP: on · Viewport: SMXL-HiDPI