Démarrage d'un PIC16F1825

[invitef9ccb542]

Bonjour,

Je viens encore solliciter l'aide des spécialistes du PIC.
J'ai un PIC16F1825 que je programme avec un PicKit3.
Le programme est tout bête, il fait allumer une LED branchée sur RC3, le pic est maintenant alimenté par sa propre alim et non par le pickit3.
Ce programme s’exécute sans problème avec le debugger, en mode pas à pas, et la LED s'allume.
Lorsque je débranche mon pickit, que je coupe et remet l'alim du pic, le programme ne démarre pas (en tout cas il n’exécute pas le code qui allume la LED).

Voila mes questions:
1) Y a-t-il des flags dans la configuration à positionner d'une certaine manière pour que le pic démarre?
Notez que j'utilise l'oscillateur interne et voici la config:

__CONFIG _CONFIG1, _FOSC_INTOSC & _WDTE_OFF & _PWRTE_OFF & _MCLRE_ON & _CP_OFF & _CPD_OFF & _BOREN_OFF & _CLKOUTEN_ON & _IESO_OFF & _FCMEN_OFF
__CONFIG _CONFIG2, _WRT_OFF & _PLLEN_OFF & _STVREN_OFF & _BORV_19 & _LVP_OFF

2) Quelles sont les causes les plus courantes pour que le micro ne démarre pas?

merci
-----

[RISC]

Salut,

Peux-tu faire voir ton schéma électronique ?
C'est nécessaire pour savoir si les bits de configuration conviennent.

Peux-tu fair voir ton code de clignotement de LED ?

As-tu recompilé ton programme en mode Programmer et Release avant de détacher ta carte de ton Pickit3 (C'est OBLIGATOIRE) ?
En mode Debugger l'image HEX est différente du mode Programmer. Il est interdit de débrancher la carte (sous peine de non fonctionnement) si elle a été flashée en mode Debugger...


a+

[invitef9ccb542]

Bonjour,

Merci pour ton aide.
J'ai joint le schéma on ne peut plus simple.

Voici le code:

list p=16f1825 ; list directive to define processor
#include <p16f1825.inc> ; processor specific variable definitions

;------------------------------------------------------------------------------
; CONFIGURATION WORD SETUP
;------------------------------------------------------------------------------

__CONFIG _CONFIG1, _FOSC_INTOSC & _WDTE_OFF & _PWRTE_OFF & _MCLRE_ON & _CP_OFF & _CPD_OFF & _BOREN_OFF & _CLKOUTEN_ON & _IESO_OFF & _FCMEN_OFF
__CONFIG _CONFIG2, _WRT_OFF & _PLLEN_OFF & _STVREN_OFF & _BORV_19 & _LVP_OFF

;------------------------------------------------------------------------------
; RESET VECTOR
;------------------------------------------------------------------------------

ORG 0x0000 ; processor reset vector
PAGESEL START
GOTO START ; When using debug header, first inst.
; may be passed over by ICD2.

;------------------------------------------------------------------------------
; INTERRUPT SERVICE ROUTINE
;------------------------------------------------------------------------------

ORG 0x0004
RETFIE ; return from interrupt

;------------------------------------------------------------------------------
; MAIN PROGRAM
;------------------------------------------------------------------------------

START

BANKSEL PORTC
CLRF PORTC
BANKSEL LATC
CLRF LATC
BANKSEL ANSELC
CLRF ANSELC
BANKSEL TRISC
MOVLW B'00110111'
MOVWF TRISC
BANKSEL PORTC
MOVLW B'00001000'
MOVWF PORTC

GOTO $

END

Bon évidemment, si je compile en mode release et que j'utilise le programmer plutôt que le debugger, mon programme démarre.

Après lecture attentive de la datasheet du pic16f1825 il apparaît qu'il existe plusieurs façons de déclencher un reset :
- action sur la broche MCLR
- Power On Reset (POR), donc dépendant de VDD
- Brown-Out Reset (MOR), donc dépendant de VDD

Ma question concerne les deux modes POR et BOR:
- peut-on se contenter du POR, l'alimentation et-elle toujours suffisante même si l'on plonge en dessous des limites du BOR à 1.9V?
- quelle est la finalité du BOR? s'agit_il de garantir le bon fonctionnement des périphériques plutôt que celui du pic?

merci

[RISC]

Salut,

Pourquoi programmes-tu en assembleur ???
La version Lite du compilateur HiTech pour PIC10/12/16 est gratuite.

Le POR sert à la mise sous tension (croissance de l'alimentation).
Le BOR sert à la perte de l'alimentation pour garantir un état connu du micro et des broches si Vdd passe en-dessous de la zone garantie, sans quoi le fonctionnement du micro est imprévisible.
Si tu écris un handler de RESET, en testant des bits tu peux savoir quelle était la raison du RESET.

a+

[A voir en vidéo sur Futura]

[invitef9ccb542]

Merci,

Donc le BOR est indispensable pour garantir le bon fonctionnement quelle que soit l'évolution de la tension.

Concernant le choix compilateur/assembleur j'hésite encore, voila pourquoi:
- je connais mal les PIC, et leur périphérique, et la programmation en assembleur oblige à initialiser et comprendre chaque registre. La programmation en C va laisser des zones d'ombre empêchant de savoir si tel ou tel registre a bien été initialisé.
- ma première application est limité, il s'agit juste de faire clignoter une LED en fonction de l'état de décharge d'une batterie.
- enfin c'est pour un usage commercial et je ne sais pas si les versions LITE le permettent.

[RISC]

Salut,

Si tu veux développer de la qualité logicielle, même pour des choses simples, un langage évolué (comme le C) va de facto éliminer tout un tas d'erreurs...
Exemple pour les PIC16F1xxx et les anciens PIC16Fxxx, cela t'évite de te tromper de banque (erreur la plus courante en ASM).
Le compilateur C génère les changements de banque quand c'est nécessaire.

Le compilateur Hitech version Lite pour PIC16F1xxx (comme tous les autres compilateurs Microchip en version Lite) autorise l'utilisation commerciale sans limitation (c'est écrit dans la license d'utilisation). Tu peux donc utiliser ce compilateur pour des applications professionnelles.

a+