Problème conversions analogiques ADC sur PIC24FJxxx

[invite7b66e893]

Salut le forum,

J'ai un gros soucis au niveau du module ADC de mon PIC24FJ256GB106.

Je l'ai paramétré pour scanner 9 entrées analogiques: AN2 à AN10, chacune de ces entrées mesurant, à travers une R série de 3.3k une tension issue d'un potentiomètre de 10k branché sur l'alim 3Vdc (cf schéma "potar" de l'Explorer 16). => voir schéma joint

J'ai tester mes fonctions sur l'explorer 16 et d'autres cartes perso, elles fonctionnent à merveille, quelque soit le nombre d'entrées ANA convertie. Mais sur cette nouvelle carte, les résultats sont plus qu'étranges.

J'obtiens comme seules valeurs converties 0x00, 0x7F, 0xFF, 0x17F, 0x1FF, 0x2FF, 0x37F ou 0x3FF et ceci sur les 9 voies. Ces valeurs ne sont pas réparties de manière homogène sur la plage de variation du potar (mono tour), mais sur une très très faible portion vers le dernier quart lorsque le curseur approche la masse.

Ceci me laisserait à penser que les multiplexeurs internes ou bien le module ADC a pris une châtaigne, qu'en pensez vous? (j'ai testé ces mêmes entrées en mode digital, elles fonctionnent)

J'ai remplacé la R de 3.3K par une 470 ohms et supprimé la capa de 10nF afin d'avoir exactement le même montage que présenté dans l'explorer 16 pour mesurer la tension issue du potar de 10k ==> mêmes résultats bizarroïdes.

J'ai repris des routines données dans les notes d'appli et datasheet Microchip, essayer plusieurs config, désactiver le scan des entrées et en convertir une seule, paramétré des temps d'échantillonnage et de conversion au max, etc., pas d'amélioration.

Autre truc que j'ai remarqué: lorsque je fais varier un curseur, il semble agir sur les autres voies, je m'explique ==> je place tous les curseurs sur le 3V (les résultats de conversion donnent tous 0x3FF), puis j'en fais varier un jusqu'à 0V, et les résultats de conv de 1 ou 2 autres voies sont également modifiés (passant de 0x3FF à 0x1F ou 0x1FF par exemple), comme s'il y avait du "crosstalking".

J'ai aussi vérifier que toutes les alimentations du MCU (en particulier Avdd et Avss) étaient aussi bien reliées au régulateur 3Vdc



Est ce que ces phénomènes vous font penser à quelque chose?
Si vous voyez autre chose à me faire tester ou vérifier?

Merci d'avance pour votre aide, parce que ça fait 2 jours que je m'arrache les cheveux sur ce module ADC que j'ai aucun soucis à faire fonctionner d'habitude
-----

[invitef86a6203]

il faut un potentiomètre linéaire non pas un logarithmique .
Fait des tests avec des ponts de résistances...

[invite7b66e893]

Bon ça n'a pas déchainé les foules mon problème...

Merci freepic, mais je n'utilise pas de potar log mais bien linéaire. Les tests avec les ponts de R n'auraient servis a rien.

Entre temps j'ai trouvé d'où venait le problème.

Comme indiqué sur le schéma joint, sur ce hardware, l'ICSP utilisé est le numéro 1 (broche 16: AN0/Vref+/PGED1 et broche 15: AN1/Vref-/PGEC1) alors que sur les autres hardwares cités dans mon premier message (sur lesquels je n'avais pas de soucis avec l'ADC) j'utilisais l'ICSP2.

J'ai remarqué qu'en travaillant en DEBUG (real ice branché sur ICSP1) j'obtenais les résultats surprenants décrits précédemment, bien qu'au niveau de la configuration de l'ADC, je lui indiquais d'utiliser comme référence de tension les Avdd et Avss (ADCON2.VCFG = 0b000).

Ensuite j'ai changé de mode de fonctionnement, et j'ai utilisé le Real-Ice en programmateur seulement pour laisser tourner ma board en "Release" (donc sans le Real-Ice branché sur ICSP) et la, sans changer de configuration, tout fonctionne correctement à nouveau.

Il y a donc un conflits sur les bornes AN0/AN1 lorsqu'on utilise le module ADC et le Real-Ice en DEBUG sur ces mêmes entrées, même si celles ci ne sont utilisées que pour ça !

J'espère que ce message permettra à d'autres de solutionner un même problème.

[inviteeb160de1]

Quand on choisit un microcontroleur, ou lorsqu'on est confronté à un probleme, imaginer que le micro est cramé est rarement une bonne idée car tres peu probable.
Par contre, lire l'ERRATA est toujours une bonne idée.
Celle de ton PIC est ici :
http://ww1.microchip.com/downloads/e...Doc/80369k.pdf

Et oh magie, le point 24 souleve le probleme suivant :

"When using PGEC1 and PGED1 to debug an
application on any 64-pin devices in this family, all
voltage references will be disabled. This includes
VREF+, VREF-, AVDD and AVSS."

Ce qui explique ton probleme...Tu n'as vraiment pas eu de bol, il fallait que selectionnes ICSP1 sur un PIC 64 pins...

En esperant t'avoir converti à la pratique de la lecture des errata, qui evite de faire des erreurs si facilement evitables...

Aurélien

[A voir en vidéo sur Futura]

[invite7b66e893]

Yep, honte à moi j'ai zappé l'Errata, tellement sur de mon coup...

Le point positif dans l'histoire, c'est qu'en faisant cette erreur je m'en souviendrais !!!

Pourtant je les lis habituellement, mais quand tout va bien pendant un moment, on perd le réflexe Errata... Le pire c'est qu'en le relisant je me souviens de m'être fait la réflexion qu'il faudrait prendre des précautions avec le module ADC.

Edit: imaginer que le µC est cramé est peut être peu probable, mais ça arrive, ici les protos sont tous montés à la main, avec un simple fer à souder, donc il arrive (parfois) que des soudures soient mal faites ou bien qu'il y ait des CC, en particulier sur les puces à forte densité de broches. Plus d'une fois j'ai du changer des µC car il y avait des CC entre broches d'alim et I/O.