Forum

Bonjour à tous

Pour beaucoup d'application sur batterie il est intéressant de connaitre l'état de charge de celles ci

Le dsPIC4013 possède une fonctionnalité interne permettant de suivre l'évolution de la tension d'alimentation du microcontroleur, mais aussi de détecter un seuil de tension sur la pin LVDIN (si le micro est alimenté par un régulateur alors une image de la tension batterie est envoyée sur la pin LVDIN par un pont résistif)

Seulement voila bien que j'ai suivi scrupuleusement la doc Microchip "dsPIC Family Reference Manuel pages 231:236 et particulierement le paragraphe 9.2.1 LVD Initialization Steps" il ne fonctionne pas !

Voici le pg élémentaire en assembleur:

;**********************************************************

_main:

;configuration pin A11 en sortie pour led témoin batterie baible

bclr TRISA,#11 ;pin A11 en sortie led témoin batterie
bclr LATA,#11 ;led témoin batterie faible éteinte

;configuration pin F0 en sortie pour Led témoin entrée 'boucle'

bclr TRISF,#0 ;pin F0 en sortie led témoin entrée dans boucle
bclr LATF,#0 ;led témoin entrée dans boucle eteinte

;configuration pin LVDIN (Low Voltage Detection

bset TRISB,#2 ;pin RB2 (commune avec LVDIN) en entrée
bclr ADPCFG,#2 ;pin RB2 (commune avec LVDIN) en analogique

;configuration registre RCON

bset RCON,#8 ;config entrée sur LVDIN
bset RCON,#9 ;config entrée sur LVDIN
bset RCON,#10 ;config entrée sur LVDIN
bset RCON,#11 ;config entrée sur LVDIN

bclr IEC2,#LVDIE ;interruption inhibée
bset RCON,#LVDEN ;mise en sce LVD


btss RCON,#BGST ;test stabilité source référence interne
bra $-2

bclr IFS2,#LVDIF ;efface drapeau

;le super programme !

Boucle:

bset LATF,#0 ;allume led temoigne de l' entrée dans boucle
bclr LATA,#11 ;éteint led temoin batterie

btsc IFS2,#LVDIF ;test drapeau indiquant tension batterie faible
bra BattFaible ;drapeau à 1 batterie faible
bra Boucle ;drapeau à 0 tout va bien

BattFaible:

bset LATA,#11 ;allume led temoin batterie faible
bra BattFaible

;**********************************************************

Voila pour ce programme qui a un fonctionnement étrange:

En effet quelque soit la tension appliquée sur la pin LVDIN , le flag batterie faible se mette à 1 au bout de 1/4 de seconde environ.J'ai le temps d'apercevoir ce délais entre l'allumage de la led témoin d'entrée dans la boucle et l'allumage de la led batterie faible , si le flag était mis à 1 dès l'entrée dans la boucle je verrais les 2 led s'allumer en même temps.


J'ai posé la question sur le forum Microchip mais pas de réponse...

Quelqu'un aurait il la solution à ce ardu problème ?

Merci d'avance

@pluch

Bonjour obdh

A vrai dire je ne comprends pas ta réponse ?

J'utilise MPLAB IDE V8.50 avec ICD2 .

Le montage est sur une maquette d'essai sur laquelle est dévellopé d'autres fonctions.Le montage fonctionne parfaitement

Ce n'est pas un montage issu d'Elektor

Je maitrise bien la programmation en assembleur de dsPIC4013 pour y avoir utilisé presque toutes les fonctions

Pour la recherche du pb , Il semble qu'on ne peut utiliser les Stimulus de MPLAB qui nécessiterait dans ce cas l'entrée d'une valeur analogique

La simulation avec MPLAB fonctionne correctement mais ne présente aucun intérêt

Le débuggage avec l'ICD2 ne fonctionne pas (?)

J'ai posé cette question sur le forum Microchip et sur un autre forum mais le pb ne semble pas connu ?

Alors le mystère subsiste , je supposais pourtant que cette fonctionnalité était d'un usage très répandue....

Merci pour tout tuyau

@pluch

Ma question était pour savoir si un problème matériel pouvait être l'origine de la difficulté. Visiblement, c'est peu probable, mais pas forcément exclu.
Quant à la simulation sous MPLab, je ne sais pas l'utiliser, ça n'a à mon avis que peu d'intérêt (contrairement à d'autres cas, analogique, vhdl...).
L'outil ICD2 est à oublier, j'en ai un qui traîne quelque part, le Real Ice fonctionne vraiment mieux et mérite l'investissement.
Je ne fais quasiment que du PIC32, j'ai fait aussi du PIC24, mais uniquement en C. J'avais réservé l'assembleur aux programmes minimalistes sur PIC10 pour son boîtier miniature SOT23, mais j'ai fait quelques essais en C, et j'abandonne définitivement l'assembleur !
J'ai trouvé une fois un bug silicium dans un PIC24 sur le spi, confirmé à retardement par Microchip, et qui m'a proposé un contournement logiciel totalement inefficace, alors que j'avais déjà mis en place un contournement matériel simple. J'ai aussi trouvé quelques bug dans les librairies, mais la plupart du temps ce sont des pièges de la documentation et des multiples fonctions partagées. Et c'est là qu'un bon outil comme le Real Ice est primordial. En aveugle (ce que je crois comprendre, en lisant que le debuggage ICD2 ne fonctionne pas), ça devient vite compliqué.
Désolé de ne pouvoir aider plus.

Une mesure à l'oscilloscope des tensions d'alimentation et d'entrée du module doivent impérativement être faites avant de chercher un problème ailleurs.

Le C ne change bien sûr rien au problème, et là, c'est en effet très simple. C'était juste pour dire que je trouve l'assembleur peu lisible, et en général non nécessaire avec les compilateurs actuels sur des processeurs sérieux.
Pour en revenir au sujet, j'ai lu la doc de la partie concernée et je n'ai rien vu de spécial. Mais il y a quelques pièges chez Microchip, c'est souvent écrit quelque part dans la doc, mais pas forcément très visible en première lecture.
Suggestions : ajouter un compteur dans la boucle et mettre un point d'arrêt lorsque le flag change, pour voir si les valeurs sont toujours identiques. Voir aussi en exécution pas à pas, qui peut mettre en évidence un timing non respecté dans l'accès aux périphériques.
Mais si le mode debug n'est pas utilisable, c'est chaud...
Attention quand-même aux platines d'essais. Les masses et les alimentations doivent être propres, sans bruit excessif. Le processeur peut très bien fonctionner correctement sur une alim "limite", et le circuit LVDIN être perturbé. Une vérification à l'oscilloscope est indispensable, en plus d'une réalisation propre. Le fait que "ça fonctionne" n'est absolument pas un test et peut cacher beaucoup de problèmes latents.
Une photo de la maquette ?

Je pensais à un compteur en ram, en mode debugger , si ça fonctionne bien sûr. Maintenant, si en mettant l'entrée à 0 et que ça plante, c'est en effet curieux.
Il ne faut pas attendre une réponse rapide de Microchip. Leur première réponse au bug que je leur avais remonté était "should work", avant de reconnaître seulement 15 jours plus tard qu'il y avait bien un bug.
D'autant plus que cette fonction LVDIN ne semble exister que sur le pic30, même pas sur son successeur le pic33. J'ai quelques pic33 en tiroir jamais utilisés, je ne peux donc pas faire l'essai (en plus, en TQFP...). Sinon, c'est une fonction facile à faire avec un simple circuit de gestion de reset (un comparateur avec référence interne et fonctionnement garanti pendant les baisses de tension) connecté à une IT processeur.
Pour le C, c'est juste un avis, je fais beaucoup de TCP/IP avec de grandes quantités de code, l'assembleur n'est même pas envisageable. Pour les FIR, c'est en effet le cas où un bout d'assembleur peut être plus efficace, encore que des librairies C intègrent directement des bouts d'assembleur. Et les dsp Microchip sont loin d'être les plus efficaces dans ce domaine. Les FPGA sont aussi des concurrents redoutables. Mais ce n'est pas le débat, et surtout, il faut choisir le matériel en fonction des besoins.
Les Microchip (surtout les derniers) sont de très bons composants, peu coûteux, avec de nombreuses piles logicielles de qualité et gratuites, ce qui est déterminant pour certaines applications.
Mais si l'ICD2 ne fonctionne pas en debug, il faudrait déjà trouver une solution.

Yves a trouvé la réponse !
Chez Microchip, avant d'utiliser un processeur, il faut en effet commencer par lire les errata, mais on prend parfois peur ! Je ne sais pas comment ils font pour avoir autant de bugs ! Ceci dit, dans la plupart des cas, ça fonctionne bien.
Donc, la configuration LVDL ="1111" ne fonctionne pas, il faut passer par le diviseur interne.

Je viens de lire les Erratas... Dommage que le 1er avril soit déjà loin!!

Issue 16 : The external Low-Voltage Detect (LVD) module is not connected to the AN2 Pad.

Le module interne n'est pas relié à la patte!!!!
Donc on peut toujours chercher!!!

Le bug concernes les rev. A1 et A2 et il ne semble pas y en avoir de plus récentes.

Jean, tu confirmes utiliser une rev. A1 et A2?

Moi aussi, il m'arrive d'oublier de regarder les errata Microchip quand j'utilise un nouveau processeur. En revanche, en cas de problème, c'est le premier réflexe, connaissant justement Microchip !
Pour le problème soulevé, le module LVDIN semble pouvoir quand-même être utilisé, à condition de passer par le diviseur interne qui est connecté directement à l'alimentation du processeur.
Sinon, n'importe quel circuit de gestion de reset est susceptible de convenir. La série STM812SW16F par exemple, peu coûteuse ni encombrante, mais il y en a plein d'autres. Il suffit de connecter la sortie sur une entrée interruption du processeur, et cela devrait fonctionner.

Merci encore

Ravi de toutes ces réponses

J'ai essayé d'approfondir un peu et de connaitre le Device ID d'après la doc Microchip ds70102 qui précise la méthode .....lire le device ID à l'aide de la commande "Readd" ? Inconnu pour moi et la lecture de la mémoire avec ICD2 n'apporte rien...

Souvent les micros sont alimentés par une tension non stabilisée 'piles ,accus)...mais moi en utilisant l'ADC avec des capteurs qui ont leurs propres alimentations il me fallait garantir la stabilité de la tension micro d'ou l'alimentation par une tension stabilisée..... et donc il me fallait avoir recourt à la pin LVDIN pour détecter une baisse de tension , je ne peux en effet pas utiliser le Low Voltage Detect puisque l'alim est constante.......

Mais je fais peut être une erreur , peut on alimenter le micro avec une tension non stabilisée et alimenter la partie ADC avec une tension stabilisée (AVDD et AVSS), ca résoudrait mon pb ?

Merci pour votre aide

@pluch

Merci Loblick

Donc si j'ai bien compris , j'alimente le micro avec la batterie et AVDD par un régulateur bien propre

j'utilise en effet Vref+ pour l'ADC (pas Vref- donc grnd) pour une meilleur précision par rapport à ma plage de tension à numériser

Par contre le résultat est ratio-métrique à Vref+-Vref- bien sur si on utilise ces Vref

En 12 bits la valeur convertie N correspondant à la tension analogique Vanal est

N=(Vref+-Vref-)/4096*Vanal

et dans le cas ou on utilise Vref est ce utile de stabiliser AVDD ?

Merci pour ta participation

@pluch