Problème carte Explorer 16 et dsPIC33FJ256GP710A Microchip

[AxS44]

Bonjour,

Je viens demander conseils sur ce forum car je suis en stage avec un collègue et nous devons tout les deux développer un programme sur le dsPIC33FJ256GP710A et sa carte Explorer 16. Pour info l'objectif est d'utiliser l'ADC et l'UART2 pour communiquer avec le PC, ainsi qu'un algorithme propre à chacun de nos sujets.
Seulement nous avons rencontré cette semaine de nombreux problèmes que nous expliquons difficilement, notamment un en particulier qui reflète sûrement la causes principale.
En fait, avec les programmes simples que nous avons implémenté dans notre microcontrôleur respectif (avec un allumage de LED pour vérifier le fonctionnement), nous avons souvent un comportement différent lorsqu'on décide de mettre ce même programme sur l'autre microcontrôleur (si ce n'était pas clair, nous en avons un chacun, et une carte Explorer 16 chacun). On voit notamment des LEDs s'allumer différemment. Nous avons aussi une entrée qui est maintenant par défaut à l'état haut alors qu'en début de semaine elle était naturellement à l'état bas.
Nous nous sommes dit que cela pouvait venir d'une éventuelle mémoire (morte). Mais nous n'avons pas trouvé de moyen d'effacer la mémoire du microcontrôleur sur MPLAB X IDE. Est-ce que quelqu'un a déjà rencontré ce genre de problème ou saurait l'expliquer ? Nous sommes désormais un peu sous pression étant donné que nous avons du retard sur notre planning. Une explication rationnelle serait vraiment bienvenue !

Merci d'avance
-----

[Jack]

Bonjour et bienvenue sur FUTURA.

Tu es nouveau, ce qui peut excuser certains oublis. Il faudra respecter à l'avenir les règles et consignes situées au début de chaque forum. Tu y noteras que ce qui concerne les µcontrôleurs doit être traité en électronique:http://forums.futura-sciences.com/pr...ves-forum.html

[spown]

Bonjour/bonsoir est bienvenue sur FUTURA,

C'est pas bien clair ton probablement. ( désolé )

Est ce que les 2 cartes roulent avec même vitesse d'horloge ? Si oui, combien ? et comment c'est déclarer pour les 2 ?

Note : la configuration des oscillateurs pour les DsPIC ça se fait dans le main.

Pour supprimer tout , il faut cocher 'Erase All Before Programming' dans propriétés projet --> ton programmeur

[AxS44]

Merci,

donc pour clarifier la problématique, nous travaillions finalement sur la même base de programme afin de se simplifier la tâche. Nous avons choisi une fréquence de cycle de 40 MHz.
Pour les deux programmes, l'horloge est déclarée comme tel :

_FOSCSEL(FNOSC_PRI); // utilisation du quartz de 8MHz externe
_FOSC(FCKSM_CSECMD & OSCIOFNC_OFF & POSCMD_XT); // pin OS2 garder pour l'horlohe
// oscillateur XT
_FWDT(FWDTEN_OFF);

Puis elle est initialisée comme ceci :

CLKDIVbits.PLLPRE = 0; // N1 = 2
CLKDIVbits.PLLPOST = 0; // N2 = 2

PLLFBDbits.PLLDIV = 38; // M = 40

__builtin_write_OSCCONH(0x03); // fonction appelant du code assembleur
// configuration du registre NOSC (OSCCON) -->
// 011 = Primary Oscillator with PLL (XTPLL, HSPLL, ECPLL)
__builtin_write_OSCCONL(0x01); // Active la commutation de la clock
while(OSCCONbits.COSC != 0b011); //
// Wait for PLL to lock
while(OSCCONbits.LOCK!= 1) {};

En espérant avoir été assez clair cette fois. Et concernant l'instruction "Erase all before programming" la case est déjà cochée donc à priori ça ne vient pas de ça.

[A voir en vidéo sur Futura]

[antek]

Mais nous n'avons pas trouvé de moyen d'effacer la mémoire du microcontrôleur

Quelle mémoire ?
Mémoire de travail (ram) ?

[extremgear]

mettez le code complet .
les 2 mcu sont bien les même ?

Pour commencez essayer de flasher un soft tout fait ( genre démo microchip , c'est pas ça qui manque sur leur site) pour écarter tout problème hardware.

[Jack]

A quoi sert d'effacer la mémoire du µContrôleur ici?

[AxS44]

En fait nous n'avons plus ce problème sur notre programme actuellement car nous l'avons repris à zéro. Mais c'est un problème que nous avons eu plusieurs fois la semaine dernière et qu'on nous cherchions à comprendre afin d'éviter de le rencontrer de nouveau. Les mcu sont exactement les mêmes (dsPIC33FJ256GP710A). Actuellement le programme ne correspond plus exactement à celui que l'on avait implémenté et qui montrait un fonctionnement différent sur les deux dsPIC. Nous avons pensé à un problème de RAZ de la mémoire ROM ou flash (je ne suis pas spécialiste) car à priori il n'y a pas de raison qu'un programme se charge différemment dans un mcu ou un autre. Mais cela ne vient pas de ça car la case correspondante est déjà cochée dans les propriétés de l'ICD3 que nous utilisons. Je sais que ce n'est pas facile à diagnostiquer sans un code correspondant, mais je pensais plutôt à une cause venant de la carte plutôt que du code qui de toute façon est identique; sachant que nous avons aussi observé le fait étrange de certaines entrées qui sont restées par défaut à 3,3 V, alors qu'il y a une semaine elle étaient par défaut à 0 V lors des tests (j'entend par défaut l'état de la pin si on la laisse non connectée). Si l'on retrouve ce phénomène alors je mettrai le code qui nous l'a causé. Je me rappelle qu'à un moment nous avons écrit dans PORTC afin d'initialiser les pins du port, mais cela n'est pas autorisé il me semble ? Il doit être utilisé seulement en lecture pour les entrées ? Je précise que nous débutons la programmation sur les dsPIC

Merci de votre aide

[RISC]

Salut,

J'utilise la carte EXPLORER16 depuis des années et j'ai changé au moins dix fois de module processeur en fonction de mes besoins (PIC24F, dsPI33, PIC32).
Le fait que les LEDs soient plus ou moins brillantes est totalement normal :
il faut tout d'abord analyser le schéma électrique (voir le user manual de la carte) pour s'apercevoir que certaines broches sont à la fois utilisées en entrée et en sortie (leds / boutons poussoir). Si ces broches sont initialisées correctement dans le programme pour matcher le hardware de la carte, les leds seront complètement éteintes ou complètement allumées.
La led complètement à gauche, partage une broche avec le JTAG qui est prioritaire. Le JTAG est activé par défaut au reset. S'il est désactivé dans les bits de configuration ou dans le programme, la LED deviendra controlable.
Il suffit donc de :
1/ lire le manuel de la carte
2/ initialiser les périphériques du dsPIC pour s'adapter au circuit électronique de la carte et ensuite tout devient opérant.
Je recommande très très fortement d'utiliser les exemples de code de Microchip pour démarrer, cela vous fera gagner des semaines... :
Voir au bas de cette page.

a+

[AxS44]

D'accord, en effet le fait que les LEDs aient plusieurs rôles nous paraissait envisageable. Pour l'histoire du JTAG je n'avais pas fait attention et c'est vrai que ça peut expliquer un fonctionnement étrange. En tout cas pour le moment nous ne rencontrons pas particulièrement ce problème mais il nous arrive d'avoir des soucis différents qui rendent à chaque fois plus compliqué de distinguer la cause, notamment un faux contact sur la carte PICtail Plus ou bien des soucis de mesure à l'oscilloscope (donc externe au micro). En tout cas merci pour votre aide, nous faisons désormais plus attention à tous ces "détails" !