PIC24E - Timer 32-bit qui ne prend pas en compte la valeur de période/prescaler

[AstroFOX]

Bonjour,

Je suis en train de jouer avec les Timers du PIC24E pour mettre au point ma bibliothèque, et dans la configuration en 32-bit (mise en cascade de 2 Timers), j'observe un comportement inattendu.

J'utilise les Timer 2 et 3 en compteur 32-bit, en freerunning sans interruption. j'utilise le Timer 1 pour récupérer à intervalle régulier (1 ms) les valeurs des Timers 2 et 3 (TMR2 pour le Timer 2, et TMR3HLD pour le Timer 3) et les afficher sur un terminal.

La valeur de TMR2 s'incrémente super vite même avec PR3 et PR2 chacun à 0xFFFF et prescaler à 1:256 (TCKPS à 0b11), j'utilise la fréquence d'horloge du CPU comme référence (70 MHz).
Avec la configuration au maximum je devrais avoir une base de temps très lente de l'ordre de 15.000 secondes (1/70.000.000)*256*0xFFFFFFFF.

Y aurait-il un paragraphe que j'ai loupé concernant la non disponibilité du prescaler en mode 32-bit?

Mon code est presque une copie conforme de l'exemple 11-6 du PIC24E FRM Timers :

T3CONbits.TON = 0;	// Stop any 16-bit Timer3 operation
T2CONbits.TON = 0;	// Stop any 16/32-bit Timer2 operation
T3CON=0;		// Clear Timer 3 config register
T2CON=0;		// Clear Timer 2 config register
T2CONbits.T32 = 1;	// Enable 32-bit Timer mode
T2CONbits.TCS = 0;	// Select internal instruction cycle clock
T2CONbits.TCKPS = 3;	// Select 1:256 Prescaler
TMR3HLD = 0;		// Clear 32-bit Timer (msw)
TMR3 = 0;		// Clear 32-bit Timer (msw)
TMR2 = 0;		// Clear 32-bit Timer (lsw)
PR3 = 0xFFFF;		// Load 32-bit period value (msw)
PR2 = 0xFFFF;		// Load 32-bit period value (lsw)
IPC2bits.T3IP = 0x01;	// Set Timer3 Interrupt Priority Level
IFS0bits.T3IF = 0;	// Clear Timer3 Interrupt Flag
IEC0bits.T3IE = 0;	// Disable Timer3 interrupt
T2CONbits.TON = 1;	// Start 32-bit Timer
debug_writeString(" - Timer32 1 started.\n");

-----

[AstroFOX]

Bonjour,
Personne n'a d'idée?

[umfred]

Au début du document, il est indiqué que ce manuel ne s'applique pas forcément à toutes les versions des dsPIC33E/PIC24E (cf la note juste avant le paragraphe introduction) et de vérifier dans le manuel du variant utilisé à la section Timers. Peut-être es-tu dans un cas où ce n'est pas applicable ?

[AstroFOX]

Je ne vois aucune contre indication dans la datasheet du 24EP512GU810 ni dans les Errata... (Timer 2/3; Timer 4/5; Timer 6/7; Timer 8/9, le Timer1 étant un cas particulier)

[A voir en vidéo sur Futura]

[umfred]

A part ça, je ne vois rien, refaire un essai avec d'autres valeurs dans le PR ?

J'ai trouvé ce sujet https://www.microchip.com/forums/m938825.aspx qui évoque un problème similaire, et un des intervenants évoque la PLL.

Il pourrait aussi être intéressant de savoir quelle période tu as actuellement

[AstroFOX]

Bonjour,

En fait je crois que c'est moi qui ai besoin de vacances! je raisonnais à l'envers : interruption du Timer1 pour observer le résultat de Timer 32 forcément j'observe l'évolution d'un Timer cadancé à 70 MHz (avec prescaler de 1, 1:8, 1:64 ou 1:256) donc l'évolution minimale sera 70 MHz/256, le registre PRx n'intervient que pour la comparaison avec TMRx pour générer l'interruption...

En utilisant l'interruption du Timer32 j'arrive à avoir la bonne base de temps en fonction du prescaler et du registre PRx : période de 1 s avec un presacler de 1:64 et PR (32-bit) = (70.000.000/64) = 1.093.750

Du coup mon (faux) problème est résolu, bug de l'interface chaise-clavier ^^