[paulfjujo]

bonjour Satinas

On est d'accord !

J'ai deja un zero dans chaque code de ma table Mcd[x] 5 bytes par item
via l'initialisation
Byte Mcd[][5]={"....","....","....","....","...."}; // 4 chars + zero par string


lors de mes tests, j'ai pu verifier , avec le debugger de mikroC ,en mode pas à pas
que j'ai bien 4 point (4x 0x2E) suivi de 0 dans chaque string, apres init
que le zero reste present avec strncpy et n=4

strncpy(Mcd[0],"1287",4);
strncpy(Mcd[1],"1134",4);


si j'init ma table avec 5 chars utiles dans le string soit 6 bytes
Byte Mcd[][5]={".....",".....",".....",".....","....."}; // 5 chars +zero par string

strncpy(Mcd[0],"1287",4); ne copie de 4 bytes ; le 5em reste à 0x2E et le 6em =0
strncpy(Mcd[1],"1134",4);

et strcpy mets bien un zero apres les 4 bytes

strcpy(Mcd[0],"1287");
strcpy(Mcd[1],"1134");


le probleme de fond est l'Effet de bord nefaste avec l'usage de copy directe valeur en ROM
(dans le code) -> vers RAM
Si le programme est court, cela passe inaperçu !

la seule parade que j'ai trouvé est la fonction StrconstRamCpy
de tranfert code ->ram
via pointeur constant et pointeur Ram

debug.JPG

il est OU , ce bug ?

[satinas]

Bonsoir

strncpy copie exactement le nombre n de caractères spécifié, et s'il rencontre un 0, il le copie, puis le duplique si n > taille source.
J'avais pas perdu mon latin. Dans la doc strncpy en français, il parle de la taille de la chaîne, c'est la taille du tableau contenant la chaîne, soit 5. Il faut bien mettre 5 si l'on veut copier la chaîne avec son terminateur. Par contre dans la doc en anglais, il parle de longueur de chaîne, et pour moi la longueur c'est 4, là c'est pas clair.

Pour le bug, envoie le projet, mais bon si c'est un bug MikroC, ...

[paulfjujo]

bonjour à tous


init de ma table

Byte Mcd[][5]={"....","....","....","....","...."};

la taille du string est dans mon cas 4 ( 4 chars + terminateur zero) = 5 bytes

la fonction strlen retourne la longueur d'une chaine, nombre de caracteres utiles, sans le zero terminateur

Code : Tout sélectionner

// test debugger  29-01-2022
   strncpy(Mcd[0],"1287",4);
   k=strlen(Mcd[0]);           
 // --->K=4   ne copy que 4 bytes          le zero terminateur existe déja dans ma table , initialisé avec des string de 4 chars
  
   strncpy(Mcd[1],"1287",5);   //   copy  5 bytes  dont  le 5em écrasé ( mais etait  déja à 0)
   k=strlen(Mcd[1]);           // -->  k=4
   
    strncpy(Mcd[2],"1287",6);   // copy  6 bytes .. comble avec des zeros   ..le 6em (zero) deborde sur la variable suivante ! 
   k=strlen(Mcd[2]);           // -->  k=4
   
      strncpy(Mcd[3],"1287",7);   // copy  7 bytes,  le 5em etait deja à 0  t rajoute 2 zero .. qui debordent sur la variable suivante  Mcd[4] !  
   k=strlen(Mcd[3]);  


dans tous les cas , j'ai K=4 ... vu qu'il y a un zero apres les 4 caracteres utiles
par contre on peut voir que ça deborde dans la table d'indice suivant ,si on copy plus de caracteres que le nombre
réservé dans l'init de la table
et là, bonjour les degats..

d'ou la necessité non seulement de declarer des variables avec la taille maximum prevue
mais aussi , les initialiser (contenu des variables) au moins une fois avant de s'en servir ...

non, ce n'est pas de l'Orangina!


voir copy watch window

debug1.jpg

[satinas]

Bonsoir
On est d'accord, je parlais de façon générale, pas de ton cas particulier ou le 0 final pré-existait.
Les chaînes en C ça a toujours été casse-gueule, vive le C++ :)

Par contre pourquoi les initialiser avant emploi, là je te suis pas ? tu peux déclarer un tableau de char à la taille max requise, sans l'initialiser avant de t'en servir. Si le but de l'initialisation est de mettre 0 en fin de chaîne pour éviter les dégâts, ce 0 peut lui aussi être effacé s'il y a bug. Donc c'est pas une assurance tous risques :)

[paulfjujo]

Bonsoir
On est d'accord, je parlais de façon générale, pas de ton cas particulier ou le 0 final pré-existait.
Les chaînes en C ça a toujours été casse-gueule, vive le C++ :)

Par contre pourquoi les initialiser avant emploi, là je te suis pas ? tu peux déclarer un tableau de char à la taille max requise, sans l'initialiser avant de t'en servir. Si le but de l'initialisation est de mettre 0 en fin de chaîne pour éviter les dégâts, ce 0 peut lui aussi être effacé s'il y a bug. Donc c'est pas une assurance tous risques :)

dans mon cas particulier ,je ne peux QUE mettre 4 caracteres numeriques dans ma variable, le zero en fin de chaine
est surtout là, quand je veux verifier /imprimer le contenu ..comme un string et non pas chaque caracteres individuellement
sinon j'utiliserai un simple tableau de 4 bytes.
je n'ai aucun risque de deborder, car ma saisie est blindée..

je prefere initialiser mes tables, variables des le debut de programme.
au moins, on sait ce qu'il y a dedans par defaut ..
La propagation d'un debordement possible ayant lieu au plus tot..
pour avoir un plantage le plus franc possible au debut de programme, plutot que d'attendre une situation tres aléatoire,
où on n'utilise (remplit) les tables qu'a un certain moment de l'execution

C'etait surtout vrai avec les 16Fxxxx et le IRP_bit (Probleme de Bank) qui se manifestait ensuite ( on est toujours sur MikroC !)
le compilo se manisfestant par ce sybilin message IRP_bit ... mais declarant No errors

ex: un buffer de texte initialisé, remplis de zero
si on y met dedans une serie de caracteres saisis au clavier et qu'on a oublié le terminateur de string
l'impression du buffer ne partira pas à vau-l'eau.

mais, tu as raison, le risque zero n'existe pas ..

Bref, il n'y a pas de solution miracle .

[paulfjujo]

bonsoir,

Encore un effet bizaroïd ...

YAT terminal connecté sur UART PIC18F27K42 via cordon Prolific USB
sur recompilation et chargement du programme HEX dans le PIC

la presentation apparait 2 fois !
la 1ere fois bug sur version .. redemarre ?
la 2em fois est par contre correcte

Presentation :
Directory :C:\_MikroC\_MesProjets_MikroC\_18F27K42_ADC_Test_on_LCD_2022
MikroC pro 7.30 Beta
Projet :Test_killed_ADC_18F27K42.mcppi
Test PIC18F27K42
Config bit : P18F27K42_FOSC_64Mhz.cfgsch FOSC:64.0 MHz
Eeprom: not used ....
Source : Test_killed_ADC_18F27K42ß Presentation:
Directory :C:\_MikroC\_MesProjets_MikroC\_18F27K42_ADC_Test_on_LCD_2022
MikroC pro 7.30 Beta
Projet :Test_killed_ADC_18F27K42.mcppi
Test PIC18F27K42
Config bit : P18F27K42_FOSC_64Mhz.cfgsch FOSC:64.0 MHz
Eeprom: not used ....
Source : Test_killed_ADC_18F27K42_2022-02.c
18F27K42 + 1 led + UART1 115200 bds
avec LCD 1602 en mode // 4 bits
Test ADC 12bits sur entree RC2

LCD 1602 init
Init ADC 1.024V for RC2 Analog input
Init Timer0 sur 1 sec
EA18= 333 pts EA18= 0.083 V
EA18= 336 pts EA18= 0.084 V

mais sur un Reset MCU
la presentation apparait correctement en 1 seule fois

----------------------------------------------------
je fais le meme TEST avec terminal VBRAY => idem
ce n'est donc pas un probleme de terminal
----------------------------------------
modification programme MikroC
Rajout attente demarrage complet Oscillateur MCU
OSCTUNE=0;
OSCCON1 = 0x60;
OSCFRQ = 0x08; // FOSC = 64MHz
Delay_ms(1000); <-- rajout
------------------------------------------
Recompilation et chargement du hex dans le PIC
Cette fois ,
La presentation apparait 1 seule fois et correctement

Presentation :
Directory :C:\_MikroC\_MesProjets_MikroC\_18F27K42_ADC_Test_on_LCD_2022
MikroC pro 7.30 Beta
Projet :Test_killed_ADC_18F27K42.mcppi
Test PIC18F27K42
Config bit : P18F27K42_FOSC_64Mhz.cfgsch FOSC:64.0 MHz
Eeprom: not used ....
Source : Test_killed_ADC_18F27K42_2022-02.c
18F27K42 + 1 led + UART1 115200 bds
avec LCD 1602 en mode // 4 bits
Test ADC 12bits sur entree RC2

LCD 1602 init
Init ADC 1.024V for RC2 Analog input
Init Timer0 sur 1 sec
EA18= 334 pts EA18= 0.083 V
EA18= 334 pts EA18= 0.083 V
EA18= 344 pts EA18= 0.086 V

MA Conclusion :
Laisser le temps au MCU , de finir le demarrage et la stabilisation de l'horloge interne
surtout à 64MHz
(ici avec Delay_ms(1000);

y a pas le feu au lac .. ni besoin de manivelle pour démarrer le MCU

le code est celui du test ADC avec VREF +1,024V

_18F27K42_ADC_Test_on_LCD_2022_Vref_1.024.zip

j'avais mis ce test , apres l'init de l'Oscillateur
while ((OSCSTAT.HFOR==0)|| (OSCSTAT.PLLR==0)) //
mais , est bloquanr +> rempacé par delay

Satinas, t'en penses quoi ?

[satinas]

Bonsoir Paul et bonsoir à tous

Je regarderais ton code.
La PLL peut être activée pour l'oscillateur externe uniquement. Donc si tu utilises l'oscillateur interne, PLLR reste à 0.

D'après la doc :

La config RSTOSC permet de sélectionner l'horloge au reset :
- soit un FOSC interne 64MHz (HFINTOSC=64MHz et COSC=6,CDIV=1), attendre le bit ready OSCSTAT:HFOR
- soit un FOSC interne 1MHz (HFINTOSC= 4MHz et COSC=6,CDIV=4), attendre le bit ready OSCSTAT:HFOR
- soit un FOSC externe (config FEXTOSC), il y a un délai au démarrage OST auto de 1024 Tck, voir aussi bits OSCSTAT:EXTOR/PLLR.

Ensuite on peut modifier HFINTOSC (s'il est utilisé) avec le registre OSCFRQ :
- HFINTOSC varie de 1 à 64Mz (CDIV inchangé ?)
- attendre le bit ready OSCSTAT:HFOR

Ensuite si le bit de config CSWEN est à 1, on peut faire du clock switching avec le registre OSCCON1 :
- NOSC pour choisir l'oscillateur interne ou externe (config FEXTOSC)
- NDIV pour choisir le diviseur 1 à 512
- après modif, attendre le bit ready OSCCON3:ORDY
- si oscillateur externe, voir aussi les bits EXTOR et PLLR, je sais pas si le test du bit ORDY est suffisant.

[paulfjujo]

bonjour Satinas,

merçi pour ta réponse


j'ai bien la PLL active, je suis bien à 64MHz pour FOSC
j'ai testé dans plusieurs cas, la lecture etat oscillateur

Nota 1 : l'alim du PIC est reliée en permanence ! le Pickit4 detecte cela.

dans la config mikroc , je n'ai que le choix Oscillateur not enabled ...
les autres choix concernent l'usage d'un quartz ou d'un oscillateur Externe

le terme Oscillateur externe est trop vague
au vu de :
FIGURE 7-1: SIMPLIFIED PIC® MCU CLOCK SOURCE BLOCK DIAGRAM
pour moi, l' oscillateur externe .. c'est
soit un quartz entre OSC1 et OSC2
soit un module oscillateur dont la sortie entre sur CLKIN/OSC1

et donc l'oscillateur INTERNE : HFINTOSC avec choix 64MHz et CDIV=1:1
dans ce cas les flags .HFOR et PLLR sont à 1 des le départ
et ne sont donc pas significatifs !

si je choisit EXTOSC with 4xPLL , with EXTOSC operating per FEXTOSC bits
OSCCON1 = 0x60;
OSCFRQ = 0x08; // FOSC = 64MHz
Etat_clock_AV=OSCSTAT; // donne 16 soit LFOR=1= The oscillator is ready to be used
while (OSCSTAT.HFOR == 0); // test Etat Ready Oscillateur OSCSTAT := 0x40 =64
Etat_clock=OSCSTAT; // donne aussi 80 , soit HFOR=1 et LFOR=1 64+16=80
// Delay_ms(1000); // affichage BAD sans delay ! et OK si Delay minimum >= à 20mS


les flags de OSCSTAT montrent bien un changement d'etat
MAIS LE PROBLEME EST LE MEME , avec l'attente de HFOR ok
l'affichage présentation est encore dédoublé
Seul un DELAY permet l'affichage normal !
Nota : j'ai pu tester que l'affichage est normal si je rajoute un Delay mS >=20mS

comme si il y avait un reset intermediaire (sans le rajout du delay ?)
je n'arrive pas à en comprendre, detecter la cause.

sur une autre appli, ayant un traitement bien plus long avant d'afficher la présentation sur l'UART
je n'ai pas ce probleme.. pas le besoin de rajouter un delay


Maintenant :
je vais rester sur une config
de type HFINTOSC with HFFRQ=64Mhz and CDIV=1:1 qui me parait la plus adéquate.
et prendre l'habitude de mettre un delay minimum de 100mS... ne voyant pas un imperatif absolu pour
que le programme ( application) demmarre tout de suite ..

Code : Tout sélectionner


le test :
   OSCCON1 = 0x60;
    OSCFRQ = 0x08;        // FOSC = 64MHz
    Etat_clock_AV=OSCSTAT;  // donne[highlight=yellow] 16[/highlight] soit LFOR=1= The oscillator is ready to be used
    while (OSCSTAT.HFOR == 0);  // test Etat Ready Oscillateur OSCSTAT := 0x40
    Etat_clock=OSCSTAT; // donne aussi [highlight=yellow]80[/highlight] , soit HFOR=1 et LFOR=1
  //  Delay_ms(1000);

  
  config projet :
  OSCILLATEUR Not enabled
  EXTOSC with 4xPLL , with EXTOSC operating per FEXTOSC bits .....(was HFINTOSC with HFFRQ=64Mhz and CDIV=1:1)
  
  Etat clock avant =  16    Etat clock apres =  80
  
 Presentation : 
 Directory :C:\_MikroC\_MesProjets_MikroC\_18F27K42_ADC_Test_on_LCD_2022
 MikroC pro 7.30 Beta 
 Projet :Test_killed_ADC_18F27K42.mcppi
 Test PIC18F27K42
 Config bit : P18F27K42_FOSC_64Mhz.cfgsch FOSC:64.0 MHz
 Eeprom:  not used ....
 Source : Test_killed_ADC_18F27K42_2022-02.c
 18F27K42 + 1 led + UAR
Etat clock avant =  16    Etat clock apres =  80
 Presentation : 
 Directory :C:\_MikroC\_MesProjets_MikroC\_18F27K42_ADC_Test_on_LCD_2022
 MikroC pro 7.30 Beta 
 Projet :Test_killed_ADC_18F27K42.mcppi
 Test PIC18F27K42
 Config bit : P18F27K42_FOSC_64Mhz.cfgsch FOSC:64.0 MHz
 Eeprom:  not used ....
 Source : Test_killed_ADC_18F27K42_2022-02.c
 18F27K42 + 1 led + UART1 115200 bds
 avec LCD 1602 en mode // 4 bits 
 Test ADC 12bits sur entree RC2 

 LCD 1602  init
 Init ADC 1.024V for RC2 Analog input
 Init Timer0 sur 1 sec
EA18=  2800 pts      EA18= 0.700  V     
EA18=  4095 pts      EA18= 1.024  V     
EA18=  4095 pts      EA18= 1.024  V     
EA18=  4095 pts      EA18= 1.024  V     


Nota 2: Rappel :
un PIC ne peut plus faire de Reset sur OFF puis ON power supply
si un cordon prolific USB reste connecté sur l'UART
la pin RX UART alimentant le PIC ! via les diodes de protection du PIC

C'est peut etre là aussi une source de probleme !
laissant l'UART toujours connecté pendant la programmation

[satinas]

Si je m'en tiens à ton code en zip, tu déclares RSTOSC à 64 MHz et FEXTOSC à not enabled.
Donc tu démarres directo en oscillateur interne 64MHz.
A mon avis, les 3 premières lignes de ton main ne sont pas nécessaires, et peuvent provoquer des délais de clock switching.
En enlevant ces 3 lignes et en testant le bit HFOR, est ce que ça marche ?

Après on parlera d'oscillateur externe et de PLL. et là c'est OSCCON1 = 0x20.
Avec OSCCON1 = 0x60 tu restes en interne 64MHz. donc ligne inutile.

On peut :
- démarrer en oscillateur interne et y rester.
- démarrer en oscillateur externe avec ou sans PLL et y rester.
- démarrer en oscillateur interne puis switcher en externe.
Et je sais pas ce que tu veux faire

Pour le reset, le programmateur doit le faire, non, sauf si tu désactives la pin Mclr ?
Dans MpLabX c'"est très long quand on clique sur le bouton reset/unreset ou quand on fait un run, même sans changer le programme. MpLab était beaucoup rapide, à moins que j'ai pas tout compris avec MpLabX :)

Toujours ce problème de démo limit pour moi :(

[paulfjujo]

En enlevant ces 3 lignes ?

meme si les 3 lignes ne servent à rien ( vis à vis de la config ) , elles montrent dans le code comment est initialisé l'horloge FOSC
car on pourrait aussi y modifier FOSC à une autre valeur que 64MHz
et activer ou pas ,la PLL
ou ajuster OSCTUNE

et en testant le bit HFOR, est ce que ça march ?

-> NON, idem ...

je laisse branché l'UART justement pour voir le résultat au démarrage !
et je pense que le probleme de fond vient que mon UART reste connecté
pendant le chargement du HEX et perturbe le RESET résultant de la fin d' 'envoi du HEX par MPLABX IPE
car
un RESET par mon BP sur l'entree MCLR redémmarre bien le MCU et
=> affichage sans probleme
un mise OFF puis ON de mon alim 5V ne reset pas mon MCU si j'ai laissé connecté mon cordon Prolific sur l'UART !
le niveau logique de RX etant 1 au repos !
si le cordon est débranché, le RESET a bien eut lieu ..mais je n'ai pas vu la presentation !
et si je le rebranche , je continue bien sur , à voir la suite du deroulement du programme

c'est un FAUX vrai probleme !
je vais donc laisser un petit délai de 100mS au démarrage et basta ..

Merçi de ton intervention