PIC18F26K22 démarrage aléatoire

[SockaRr]

Bonjours

Je suis nouveau et je cherche un peut d'aide sur un problème très étrange concernant le comportement au démarrage d'un pic18f26k22. Je sais que le forum n'est pas forcément destiné à cela mais bon je galère et j'ai pas trouver alors je me fis à vos avis ou expériences

Tout d'abord le schéma : il s'agit d'un Pic18f26k22 alimenté sur une batterie avec un régulateur à découpage LM2575. Découplage avec une condensateur de 100nF sur les bornes d'alimentation du Micro et découplage de l'entré MCLR. Concernant le reste rien d'exceptionnel, des commandes de LED grâce à des transistors, un bouton poussoir et des sorties numérique relié à un module qui contrôle l'ouverture et la fermeture d'un cadenas. J'utilise l'horloge interne du micro avec une PLL X4. Le circuit est réalisé sur de la verroboard (oui je sais c'est pas terrible).

La où ca devient intéressant c'est que le PIC ne démarre pas correctement au moment du branchement sur la batterie. Je dois provoquer un reset manuel pour que le pic exécuté correctement le code et configure les entrées sorties. Si je n'effectue pas cela, la configuration est aléatoire comme si le pic sautais des instructions volontairement. c'est d'autant plus étrange du fait que tout fonctionnais correctement ce phénomène est apparu "comme par magie" (désolé j'ai utilisé un gros mot ^^). J'ai regarder le comportement à l'allumage..... rien sur l'alimentation elle est stable et elle passe de 0 à 5V sans pic de surtension ou oscillation intempestif.

En gros je n'ai rien trouver de d'étrange niveau Hard et Soft qui expliquerai ce comportement. Je demande juste si vous avez observer des choses comparable et si vous aviez une solution. Merci d'avance

PS : Désolé s'il reste des fautes d'orthographes :S
-----

[paulfjujo]

bonjour,


Est-ce que tu testes la stabilité de l'oscillateur interne avant de rentrer dans le vif du programme ?
- Utilises tu le PWRT timer ecoulé ... pour demarrer
ou un delai de quelques diziemes de secondes.. pour laisser passer des aleas de mise sous tension
-tu commande un cadenas .. selfique ? .. parasite ?

schema et code ?

[SockaRr]

Oui j'attends que mon oscillateur soit stable avant de faire des initialisions :

void main(void){
// Init

OSCCONbits.IRCF = 0b111; // Lock osc = 16MHz
while(!OSCCONbits.HFIOFS); //wait for stable clock
RCONbits.BOR = 1;
RCONbits.POR = 1;

OSCCON2bits.PLLRDY = 1;
OSCTUNEbits.PLLEN = 1; // PLL x4 = 64MHz
while(!OSCCONbits.HFIOFS);

Concernant le cadenas pas de parasite détecter. Il se compose de son propre micro j'applique juste des états numériques sur deux de ses entrées pour effectuer l'ouverture ou la fermeture.

Et meme si j'avais des parasites sur l'alimentation je me retrouverais avec des resets intempestif pas une mauvaise config du pic?

[kevin8z]

Salut,

Tu dit avoir ds problème au moment du branchement sur la batterie, donc j'imagine qu'il y a des rebonds (comme pour un bouton poussoir). Essaye de mettre une cellule RC sur la broche MCLR histoire de laisser le PIC un certain temps à l'état de reset, ce qui permet a toutes tes tensions de s'établir correctement.
Tu peu aussi faire la même chose sur la broche ON/ON du LM2575 ce qui supprimerai les rebonds

[A voir en vidéo sur Futura]

[DAUDET78]

schema et code ?

Schéma COMPLET indispensable !

[SockaRr]

J'ai mi le circuit préconiser dans la datasheet.

Capture d’écran 2015-06-24 à 13.41.55.png

Et bien le comportement du PIC est pire...... il ne paramètre plus du tout ses entrées sorties même après un reset manuel. Du coup je suis encore plus perdu et énervé de ne pas trouver la solution ^^

Le schéma est le suivant :

Untitled.jpg

[terriblement]

Salut,

Tu as mis un watchdog en place ?
Brownout reset ?

Tu fais tes tests en mode "Stand Alone" ou en mode "DEBUG" ?

[SockaRr]

WDTEN = OFF et le Brownout j'ai pas toucher donc config standard

[terriblement]

et en mode debug ou pas ?

[paulfjujo]

L'alim 5V est -elle separée ?
Le connecteur ..est-ce la liaison ICSP ?

Pourquoi relier le VDD Pin 2 ICSP au circuit reset ?
Tests faits avec ICSP Pickit deconnecté ?

[SockaRr]

Exact erreur sur le schéma la pin 2 est relié au 5V et non au circuit de reset. Le connecteur est celui du Pickit3 et j'ai oublier de mentionner que je programme avec MplabX et le compilateur XC8.

Autre info, en mode debug le PIC tourne correctement si je fait du Pas à pas si je le laisse se démerdé c'est la panique il pert l'état de ses I/O et de ses valeurs initiale. J'hésite à changer de PIC pour voir si le phénomène se reproduit. Je me demande si il n'aurais pas pris un coup sur le circuit d'horloge..... Sa semble farfelu mais bon au points ou j'en suis.

[paulfjujo]

En mode debug, le PIC utilise plus de ressources internes (RAM..)

Comment se comporte -til en mode Release ?

Y a -t-il des warnings lors de la compilation ?

Du vecu, sous MikroC, on peut tres bien avoir une compil "Successfull"
mais un program qui plante par moment , par debordement de bank memoire
Visible seulement via les messages Warnings ..

L'alim 5V est externe ou c'est l'ICSP (donc l'USB) qui alimente le tout.. ?

[SockaRr]

en mode Release meme comportement que le debug quand je ne fait pas du pas à pas. En clair il config l'oscillateur (et encore je suis pas sur qu'il soit correct) et passe direct au while(1) sans passer par la config des I/O et des registres ADCON.

Aucun warning à la compilation. J'ai deja travailler avec plusieurs PIC18 et PIC24 c'est la premiere fois que je vois ce comportement. Je devrais recevoir un nouveau micro demain ou vendredi je suis curieux de voir si on obtient la meme chose.

Nan pas d'alim via l'ICSP je ne fait jamais ca. Alimentation via batterie avec régulateur lm2575 pour obtenir un 5V. C'est stable, commutation "franche" après branchement pas d'oscillation enfin bref l'alimentation est clean. J'ai tester avec une alimentation de labos et j'ai le meme comportement c'est se qui me fait douter du bon fonctionnement du PIC18

[DAUDET78]

Y a t'il, à ras du µC, des découplages entre Vdd à Vss ? genre 0,1µF

[paulfjujo]

j'ai ça en plus
OSCCONbits.SCS=0x10; // see DS page 37

Reste aussi à voir la Config_bits
et si celle ci est bien transferée au niveau du Pickit

J'avais remarqué qu'il fallait faire un export du Hex
puis le charger via Pickit,
car un chargement direct du Hex, apres compil , ne transferait pas
les bits de config.

void main()
{

	OSCCON=0;
	OSCCONbits.SCS=0x10;     // see DS page 37	
	OSCCONbits.IRCF	= 7;    // choix 16Mhz
	/*
	OSCCONbits.IRCF	= 6;    // choix 8Mhz
	OSCCONbits.IRCF	= 5;    // choix 4Mhz
	OSCCONbits.IRCF	= 4;    // choix 2Mhz
            OSCCONbits.IRCF	= 3;    // choix 1Mhz par defaut !!!
            */
	OSCCON2=0;
	OSCTUNEbits.PLLEN = 1;  // 1=active PLL => 10x4=40Mhz
	OSCTUNEbits.TUN=0x00;


ANSELA=0;
TRISA = 0b00001111 ; 
TRISAbits.TRISA4 = 0;   // led rouge
LATA = 0x00;

ANSELC=0;
TRISCbits.TRISC6 = 0;
TRISCbits.TRISC7 = 1;
Led_Rouge=Allume;

Init_UART1();
Put_RS('*');
CRLF();

[terriblement]

car un chargement direct du Hex, apres compil , ne transferait pas
les bits de config.

Pas normal.

fais voir tes bits de config stp.

Essaie un code minimaliste qui ne fait que clignoter une LED par exemple.

Tu peux faire une photo de ta veroboard avec l'ensemble de ton montage ?

[paulfjujo]

Pas normal.

avec MPLAB 8.92 et MPASM
1er cas
un Build all -> generant un fichier Toto.Hex ( taille 1ko)
chargé ensuite avec Pickit3
File
Import Toto.hex
fait que si les bits de config sont positionnés via Config Bits (window Config bits set in code Non coché)
on se retouve avec une config bit vu par pickit3 , erronne ex: 0FFF au lieu de 30F5
Et aussi
Pas de transfert de la partie EEPROM ( celle ci etant initialisée dans le code at 0x2100)


2em cas
si maintenant je fait ,sous MPLAB ASM
Build All
File Export
une fenetre apparait avec des options EEPROM, Config Bits , User ID , qui si elles sont cochées
genere cette fois un meme fichier Toto.hex mais de taille 13ko
une fois chargé dans Pickit3
import File Toto.HEX
j'ai bien la bonne config bit vu par Pickit3 30F5
et l'eeprom du PIC est bien initialisée avec mes datas fournies dans mon code


3em cas
si les bits de config sont positionnés dans le code (windows Config bits set in code coché)

; pour verif FOSC sur Pin3 GP4 CLCKOUT
   __CONFIG _INTRC_OSC_CLKOUT  & _WDT_OFF  &_PWRTE_OFF & _BOD_OFF & _MCLRE_ON & _CP_OFF  & _CPD_OFF & _FCMEN_OFF  & _IESO_OFF

un Build all -> generant un fichier Toto.Hex ( taille 1ko)
chargé ensuite avec Pickit3
File
Import Toto.hex
on se retouve avec une config bit vu par pickit3 OK : 30F5
La partie EEPROM est mise à jour.

Dorénavant, j'utilise plutot le fichier export , si ma config bits est fait via "MPLAB config bits window"
plutot qu'une config bits directe dans le code.



Export_file_MPLAB.jpg

Config_bit_set_in_code.jpg

nota : cette remarque sert uniquement à preter attention à une erreur possible de configuration bits..
La bonne config bit .. c'est celle vue par le Pickit3 (ou 2!)
celle qui va etre inscrite dans le MCU..

[SockaRr]

Alors je vais essayer de ne rien oublier ^^

Apres des tests pas de ras du pic juste un déblocage du pic quand je connect le pickit3
Oui j'ai un découplage sur le micro et le MCLR

Pour se qui est de l'histoire des bits de config non transmis ton histoire est étrange mais comme je possède MPLABX et XC8 aucun des cas présenté ne m'est applicable.

les bits de config

#pragma config FOSC = INTIO67 // Oscillator Selection bits (Internal oscillator block)
#pragma config PLLCFG = ON // 4X PLL Enable (Oscillator multiplied by 4)
#pragma config PRICLKEN = ON // Primary clock enable bit (Primary clock enabled)
#pragma config FCMEN = OFF // Fail-Safe Clock Monitor Enable bit (Fail-Safe Clock Monitor disabled)
#pragma config IESO = OFF // Internal/External Oscillator Switchover bit (Oscillator Switchover mode disabled)

// CONFIG2L
#pragma config PWRTEN = OFF // Power-up Timer Enable bit (Power up timer disabled)
#pragma config BOREN = SBORDIS // Brown-out Reset Enable bits (Brown-out Reset enabled in hardware only (SBOREN is disabled))
#pragma config BORV = 190 // Brown Out Reset Voltage bits (VBOR set to 1.90 V nominal)

// CONFIG2H
#pragma config WDTEN = OFF // Watchdog Timer Enable bits (Watch dog timer is always disabled. SWDTEN has no effect.)
#pragma config WDTPS = 32768 // Watchdog Timer Postscale Select bits (1:32768)

// CONFIG3H
#pragma config CCP2MX = PORTC1 // CCP2 MUX bit (CCP2 input/output is multiplexed with RC1)
#pragma config PBADEN = ON // PORTB A/D Enable bit (PORTB<5:0> pins are configured as analog input channels on Reset)
#pragma config CCP3MX = PORTB5 // P3A/CCP3 Mux bit (P3A/CCP3 input/output is multiplexed with RB5)
#pragma config HFOFST = ON // HFINTOSC Fast Start-up (HFINTOSC output and ready status are not delayed by the oscillator stable status)
#pragma config T3CMX = PORTC0 // Timer3 Clock input mux bit (T3CKI is on RC0)
#pragma config P2BMX = PORTB5 // ECCP2 B output mux bit (P2B is on RB5)
#pragma config MCLRE = EXTMCLR // MCLR Pin Enable bit (MCLR pin enabled, RE3 input pin disabled)

// CONFIG4L
#pragma config STVREN = ON // Stack Full/Underflow Reset Enable bit (Stack full/underflow will cause Reset)
#pragma config LVP = OFF // Single-Supply ICSP Enable bit (Single-Supply ICSP disabled)
#pragma config XINST = OFF // Extended Instruction Set Enable bit (Instruction set extension and Indexed Addressing mode disabled (Legacy mode))

// CONFIG5L
#pragma config CP0 = OFF // Code Protection Block 0 (Block 0 (000800-003FFFh) not code-protected)
#pragma config CP1 = OFF // Code Protection Block 1 (Block 1 (004000-007FFFh) not code-protected)
#pragma config CP2 = OFF // Code Protection Block 2 (Block 2 (008000-00BFFFh) not code-protected)
#pragma config CP3 = OFF // Code Protection Block 3 (Block 3 (00C000-00FFFFh) not code-protected)

// CONFIG5H
#pragma config CPB = OFF // Boot Block Code Protection bit (Boot block (000000-0007FFh) not code-protected)
#pragma config CPD = OFF // Data EEPROM Code Protection bit (Data EEPROM not code-protected)

// CONFIG6L
#pragma config WRT0 = OFF // Write Protection Block 0 (Block 0 (000800-003FFFh) not write-protected)
#pragma config WRT1 = OFF // Write Protection Block 1 (Block 1 (004000-007FFFh) not write-protected)
#pragma config WRT2 = OFF // Write Protection Block 2 (Block 2 (008000-00BFFFh) not write-protected)
#pragma config WRT3 = OFF // Write Protection Block 3 (Block 3 (00C000-00FFFFh) not write-protected)

// CONFIG6H
#pragma config WRTC = OFF // Configuration Register Write Protection bit (Configuration registers (300000-3000FFh) not write-protected)
#pragma config WRTB = OFF // Boot Block Write Protection bit (Boot Block (000000-0007FFh) not write-protected)
#pragma config WRTD = OFF // Data EEPROM Write Protection bit (Data EEPROM not write-protected)

// CONFIG7L
#pragma config EBTR0 = OFF // Table Read Protection Block 0 (Block 0 (000800-003FFFh) not protected from table reads executed in other blocks)
#pragma config EBTR1 = OFF // Table Read Protection Block 1 (Block 1 (004000-007FFFh) not protected from table reads executed in other blocks)
#pragma config EBTR2 = OFF // Table Read Protection Block 2 (Block 2 (008000-00BFFFh) not protected from table reads executed in other blocks)
#pragma config EBTR3 = OFF // Table Read Protection Block 3 (Block 3 (00C000-00FFFFh) not protected from table reads executed in other blocks)

// CONFIG7H
#pragma config EBTRB = OFF // Boot Block Table Read Protection bit (Boot Block (000000-0007FFh) not protected from table reads executed in other blocks)

j'ai essayer un code minimaliste tout se passe sans problème.

Autre chose j'ai commencer a tester plusieurs chose et j'ai trouver des étrangeté. Tout d'abord si je connect le pickit dans le bon ou mauvais sens (non brancher au PC) cela débloque le programme et j'ai une utilisation normal. Pas de mise à la masse du MCLR et je ne vois pas de parasite sur l'alimentation non plus.

[terriblement]

Ca ressemble beaucoup à un problème sur MCLR, essaie avec cette config :
#pragma config MCLRE = INTMCLR

Meme si il y a des choses qui semblent encore inexplicable.

Tu as pu essayé un autre PIC ?

Perso je programme toujours depuis MPLABX avec mon PICKIT 3 en cliquant sur "release" (Make and programm device), je ne génère pas de .hex ou autre. Et les bits de config TOUJOURS dans le code.

On peut avoir une photo de la vero ?