Newsgroup: it.hobby.elettronica.digitale
Titolo: PIC18LF deep sleep tiene registri x 8 min senza alimentazione?????

sono io che ho preso un abbaglio???può essere benissimo.Mi pare troppo 
impossibile.
 
normalemte :
Alimento,clock interno al micro
,mostra lampeggio rapido all'avvio,
mostra lampeggio periodico lento forever.
 
Se mando in deep sleep,tolgo alimentazione(VDD ai capi del micro 0V),attendo 
8 minuti(non ho provato oltre)
riattacco alimentazione e DOPO una frazione di secondo commuto lo switch del 
deep sleep in RUN mode mi riparte dal main loop,dove fa il lampeggio 
lento,come  l'avevo lasciato senza fare il lampeggio rapido iniziale.
Quindi vuol dire che davvero non è passato per il reset e il program counter 
è rimasto congelato?
 
Però se ridò alimetazione con lo switch in RUN mi riparte da RESET,perchè???
 
al ritorno dell'alimentazione lui non sa ancora che lo switch commuta tra 
run e deep sleep nell'interrupt(dopo che ci è passato 10 volte,tra 
l'altro),il chè mi lascia ancora più perplesso...
 
 
main
{
 
     inizializza()
     abilita_interrupt();
     set_prescaler_timer_per lampeggio_rapido();   //il toggle avviene 
nell'interrupt
     attendi_10_sec();
    set_prescaler_timer_per lampeggio_lento();   //il toggle avviene 
nell'interrupt
 
 
    while(1)
    {
    }
}//fine main
//*********************************
void Low_Int_Event (void)  //periodico con  Timer0
{
      toggle_led;
     se_ P1ON_vai in deep sleep,svegliati se P1OFF;  //metto in Hi-Z 
PORT_LED,fermo Timer0
}
//*********************************
void High_Int_Event (void)  //col timer
{
   riattiva_periferiche;//riattivo PORT_LED e Timer0 per lampeggio lento
 
 } 
 
 

  }
 
Idee sparate a caso senza leggere il datasheet, mi perdonerai
spero :P
 
Non hai nessun reset brown-out attivo?
Io non lo farei senza, anche se forse consumera' di +
se per qualche motivo la tensione scende non sai come riparte.
Non e' che il PC parte da un indirizzo a caso e finisce proprio
nel main? Se hai poche linee di programma, la flash sara' quasi
tutta vuota, non ricordo cosa fa l'opcode della flash non
programmata, credo sia un NOP e se dopo un grosso blocco non
programmato c'e' il main e' probabile che ci finisca per caso.
Se poi verifichi che non e' il PC a spasso e
*se veramente e' tutto a 0V* per accelerare i tempi prova a
riscaldarlo e vedi se riparte ancora da li' o si resetta.
 
-- 
Muvideo altrove
Fabio Eboli nella vita reale...
 
 

 -- 
belle osservazioni,ti ringrazio
però se partisse dall'inizio del main non dovrebbe comunque fare il 
lampeggio iniziale?
 
 
 
senti un pò ti intendi anche dell'uso del DSBOR?
 
il problema è che quando il condensatore di backup si scarica l'orologio 
RTCC si può fermare,se si ferma del tutto si perdono anche i valori di 
annno,mese ecc
questo mi fa comodo : se al riavvio trovo l'anno di default dico che ho 
perso l'orologio e segnalo la necessità di riprogrammarlo
 
però per tensioni intermedie avvien che l'orologio si fermi,e a quel punto 
il consumo diventa così irrisorio che per ore il supercap pare non 
scaricarsi ,***ma i registri RTCC si conservano***,per cui l ritorno 
dell'alimentazione e relativo reset trovo l'anno attuale  e non mi accorgo 
che va riprogrammato l'RTCC che ha perso delle ore
 
mi dicono che il DSBOR potrebbe essermi utile,ma si fa così?
 
es:
caso 1 )alimentazione cala per pochissimo tempo,vado in deep sleep,ma al 
risveglio riesco a rientrare nel main loop(?)senza passare da reset,il bit 
DSBOR è a 0
e continuo così
caso2)alimentazione cala molto,il DSBOR abilitato mi arma il POR ,se 
addirittura lo innesca ho un reset e  riprogrammo in ogni caso RTCC.
 
faccio riferimento a
http://ww1.microchip.com/downloads/en/DeviceDoc/93068a.pdf
 
 
grazie
 
 
 
 
 
 
 

 grazie
 
Non tocco PIC da una vita, comunque ho letto il documento che
hai linkato e ti dico come lo interpreto, ma non
ho esperienza con l'aggeggio.
Prima di tutto, se il DSBOR e' attivo non dovrebbe mai succedere
il problema del primo post, infatti sotto la tensione di BOR
il micro dovra' resettarsi cmq.
Per quanto riguarda l'RTC, dipende dalla tensione a cui hai i problemi,
se il DSBOR ha una tensione > del BOR allora se non hai il reset
(la tensione si ferma ad un valore intermedio tra le soglie)
dovrai controllare il bit. Se puoi mettere la soglia del BOR
ad un valore > del DSBOR credo che tu ottenga sempre un reset:
una volta innestato il DSBOR, questo attiva il BOR aumentando anche
l'assorbimenti di 4-5uA e accelerando la scarica del condensatore
di backup (se e' connesso ai pin di alimentazione).
 
Ciao!


 
 
Ho usato un 18lf2550 per diversi progetti e il comportamento che hai descritto non l'ho mai riscontrato.
Non conoscendo la configurazione circuitale che hai usato mi viene da porti la seguente 
domanda: togli solo l'alimentazione al micro e al resto della scheda no?
 
Ciao!
 

 ha scritto nel messaggio 
news:a41d09cf-20cf-455a...@googlegroups.com...

Ho montato su una scheda solo il micro e pochi componenti per fare una 
prova,l'unico componente alimentato č il micro,e non ci sono altri 
componenti alimentati
 
 


Condesatori di filtro sull' alimentazione ??? :-)
 

 componenti alimentati
 
Se hai tempo prova a collegare tra i piedini Vcc e GND del micro una resistenza da 1K e ripeti la prova.

 prova,l'unico componente alimentato č il micro,e non ci sono altri



Se hai tempo prova a collegare tra i piedini Vcc e GND del micro una 
resistenza da 1K e ripeti la prova.
 
Dirň di piů ,mentre č in deep sllep li cortocircuito con una pinzetta,e ho 
sempre lo stesso fenomeno 
 
 

 sempre lo stesso fenomeno
 
Ottimo, sembra che lo abbiano fatto appositamente allora. Pero' mi pare strano di non averne mai trovato traccia nei datasheet....se mi indichi che micro hai usato mi metto subito alla ricerca di info e magari me lo faccio arrivare cosi' lo testo anch'io.
Ciao!

 sempre lo stesso fenomeno
 
Ottimo, sembra che lo abbiano fatto appositamente allora. Pero' mi pare 
strano di non averne mai trovato traccia nei datasheet....se mi indichi che 
micro hai usato mi metto subito alla ricerca di info e magari me lo faccio 
arrivare cosi' lo testo anch'io.
Ciao!
 
..e magari scoprirai che ho preso una cantonata
č il 18LF24J11,che mando in deep sleep e risveglio tramite il livello 
presente su RA5,se davvero vorrai fare le stesse prove ti mando  il 
codice,sperando di non fuorviarti 
 
 

 codice,sperando di non fuorviarti
 
 
Domanda banale: quando togli alimentazione togli anche il "livello" su RA5?
 
Marco
 
 

 codice,sperando di non fuorviarti
 
Non mi è chiaro perchè mi parli di deep sleep quando nel datasheet 
http://ww1.microchip.com/downloads/en/DeviceDoc/39932D.pdf
 a pagina 4, tutti i micro LF non dispongono di tale funzione. Forse intendevi lo sleep mode?
Poi, come ha chiesto Marco, con che segnale svegli il micro?
Ciao!
 
PS: se vuoi il codice puoi mandarmelo tranquillamente

 ha scritto nel messaggio 
news:k94m46$chl$2...@tdi.cu.mi.it...

nel circuto completo il   livello sull'ingresso RA5 va a 0V quando va via la 
230V ,in circa 2 periodi=>40 ms
invece l'alimentazione del micro permane grazie al supercap di backup,il 
micro va in deep sleep,predisponendosi per risvegliarsi al ritorno del 
livello alto su RA5
 
nel circuito di prova invece non c'è un supercap,e sono io che cortocircuito 
un partitore dall'alimentazione,mettendo RA5 a 0V invece cha a 2.8v
 
ripeto la squenza
 
VDD presente con RA5 alto
RA5 va basso,il micro va in deep sleep
stacco VDD, misuro che vada quasia 0V
 
attendo vari minuti
riattacco VDD
una frazione di secondo dopo porto RA5 alto
 
mi aspetterei che il micro facesse il lampeggio iniziale,invece fa quello 
che ha quando già configurato,per cui vado a penare che abbia mantenuto vari 
registri,tra cui T0CON,che inserendo o meno un prescaler determina la freq 
del lampeggio
 
 
 

 che ha quando già configurato
 
 
L'ipotesi è che consumando così poco rimanga "alimentato" internamente, 
o se preferisci che i registri non vengano sporcati. Ma con le ipotesi 
non andiamo molto lontano :)
 
Quello che non torna è questo:
 
"When a wake event occurs in Deep Sleep mode (by
MCLRReset, RTCC alarm, INT0 interrupt, ULPWU or
DSWDT), the device will exit Deep Sleep mode and
perform a Power-on Reset (POR)."
 
 
Visto che sembra non eseguire il POr, io indagherei meglio seguendo le 
indicazioni del ds:
 
"The software can determine if the wake-up was caused
from an exit from Deep Sleep mode by reading the DS
bit (WDTCON<3>)."
 
"The software can determine the wake event source by
reading the DSWAKEH and DSWAKEL registers."
 
 
 
Tieni conto che altre modalità di sleep non prevedono il POR all'uscita.
Hai verificato che davvero sei entrato in deep sleep?
 
Ciao!
Marco
 


credo di si,perchè se non sbaglio misuravo un consumo inferiore al uA,che 
non potrei avere in altre modalità
misurerò ancora nei prossimi giorni,grazie per le osservazioni 
 
 

 ha scritto nel messaggio 
news:aedbdf95-551b-46fc...@googlegroups.com...

troppo gentili tutti
 
Hai proprio ragione,mi scuso.
Per i 18LF non si può parlare di deep sleep in quanto non c'è il voltage 
regulator da spegnere.
Misurandone il consumo pare che il loro sleep equivalga a l deep sleep dei 
18F,ma sono un pò al limite della risoluzione del mio multimetro.
Devo aumentare la R su cui leggo la caduta
 
Since Deep Sleep mode powers down the
microcontroller by turning off the on-chip
VDDCOREvoltage regulator, Deep Sleep
capability is available only on PIC18FXXJ
members in the device family. The on-chip
voltage regulator is not available in
PIC18LFXXJ members of the device
family, and therefore, they do not support
Deep Sleep.
 
 


c
 
ciao ,condivido ultime esperienze
sono passato al PIC18F24J11,in questo sveglio il micro tramite INT0
 
tra l'altro Microchip mi confonde perch� dice
 
"All external interrupts (INT0, INT1, INT2 and INT3) can
wake-up the processor from the power-managed
modes"
 
 e io vado a pensare di potere uscire da deep sleep ,
che considero un power-managed mode(sbaglio?) tramite uno qualsiasi dei 4 
external interrupt
 
,ma dice anche(in un capitolo precedente,in verit�)
 
"While in Deep Sleep mode, the device can be awakened
by a MCLR, POR, RTCC, INT0 I/O pin interrupt,
DSWDT or ULPWU event"
 
quindi solo INT0 lo sveglia da deep sleep.Non � un p� confondente tutto ci�?
 
Voglio vedere se il micro sente un blackout,va a batteria in modo deep 
sleep,e si accorge di un calo di alimentazione di batteria prima che questa 
scenda tanto da congelarmi l'RTCC.
 
 
Quindi,addormento da un certo pin che mi � comodo e risveglio da INT0.
Vedo che quando mando a dormire la tensione di core si spegne
"During deep sleep, the on-chip VDDCOREvoltage
regulator is powered down"
 
 e tramite INT0 la VDDCore ritorna.
Si passa per il RESET,riabilito i pin tramite il bit RELEASE
e uso un pin per stampare a terminale lo stato dei registri relativi a 
PowerOnReset ,BrownOutReset, DeepSleeBrownOutReset ecc e i bit interessanti
 
se mando in deep  sleep e esco prima che la tensione di batteria cali troppo 
ottengo
RCON=0xBC DSCONL=0x00 WDTCON=0xC8    POR=L  BOR=L  DSBOR=L  ---->DS=H 
<------
 
 
se durante il deep sleep la tensione scende sotto a 1.8v invece
RCON=0xBC DSCONL=0x00 WDTCON=0xC8    POR=L  BOR=L  DSBOR=L  ---->DS=L 
<-------
 
quindi cambia solo WDTCON.DS?Mi aspettavo di vedere cambiare anche DSBOR
ho quindi solo il bit DS=H  che mi pu� fare capire che il micro "ha tenuto".
 
Per ora sono arrivato qui