[Temps-x]

Bonjour paulfjujo, satinas, et tout le forum,

Et voilà.... problème résolu, lecture en mémoire programme entièrement, jusqu'à la fin, on peut encore en mettre en mémoire programme.

Je savais bien que savait déjà fait, mon problème venait d'un mauvais calcul avec la fonction decfsz, ce qui planté le programme

Fichier code plus fichier compiler, sortie sur RC1 : voir post #28

A+

[paulfjujo]

Test avec fichier de 9sec

Etape3 ,lecture datas : 50188 bytes

ecriture Bloc de 128 Bytes # 00001 @ Flash 16384 .. retour k= 0
ecriture Bloc de 128 Bytes # 00002 @ Flash 16512 .. retour k= 0
ecriture Bloc de 128 Bytes # 00003 @ Flash 16640 .. retour k= 0
ecriture Bloc de 128 Bytes # 00004 @ Flash 16768 .. retour k= 0
...etc ......
ecriture Bloc de 128 Bytes # 00382 @ Flash 65152 .. retour k= 0
ecriture Bloc de 128 Bytes # 00383 @ Flash 65280 .. retour k= 0
ecriture Bloc de 128 Bytes # 00384 @ Flash 65408 .. retour k= 0
ecriture Bloc de 128 Bytes # 00385 @ Flash 65536 ..
..............Problemo: ...................................
Projet MPLABX :18F27K42_Test_Ecr_Lec_Flash_2022-09.X
Version : 2022-0918
Compile le Sep 18 2022 a 11:33:55 UTC
avec version XC8 : 2360
Hardware : PIC18F27K42 , FOSC interne =64MHz


ça bloque soit au niveau de l'adressage 65536 ???


pas de fin de lecture restituée
... car Offset 16384 + taille datas 50188 =>la derniere adresse flash devrait etre =66 572
Plantage ! le programme reboot !



le sprintf %lu est pourtant correct , un test fait par ailleurs montre bien qu'on depasse bien 65536

Code : Tout sélectionner

/*   Test sprintf  ok
     BN=0;
     L2=16384;
     do
     {
             sprintf(CRam1," ecriture Bloc de 128 Bytes %05d    Flash @= %lu\r\n",BN,L2); 
             Print(CRam1);
             __delay_ms(2); // on est pas si pressé ce ça
             L2=L2+128;
              BN++;
     }while(BN<400);
     while(1);
     
ecriture Bloc de 128 Bytes 00381    Flash @= 65152                                                                           
 ecriture Bloc de 128 Bytes 00382    Flash @= 65280                                                                         
 ecriture Bloc de 128 Bytes 00383    Flash @= 65408                                                                            
 ecriture Bloc de 128 Bytes 00384    Flash @= 65536                                                                           
 ecriture Bloc de 128 Bytes 00385    Flash @= 65664                                                                         
 ....etc                           
 ecriture Bloc de 128 Bytes 00398    Flash @= 67328                                                                              
 ecriture Bloc de 128 Bytes 00399    Flash @= 67456
    
    */

le programme ne plante pas si j'enleve l'ecriture du bloc en flash
k=FLASH_WriteBlock(L2, p1);

Code : Tout sélectionner


   while( (L1<File_Size) && (BN<MaxBlocs))    
            // 20000h-4100h=> 131072 -16384=  114432   theorique
            // 18/09/2022 plantage à 65536
         {   
             RAZ_UART1_Buffer1();
            __delay_ms(50);     
            if(Flag_Buffer1==1)
            {  
           
               BN++;   // Block number
               L2=L1+FLASH_ROW_ADDRESS;
               p1=&Buffer1[0] ;
               cx=PORTBbits.RB1;
               sprintf(CRam1," ecriture Bloc de 128 Bytes  %05d @ Flash %lu ",BN,L2); 
               Print(CRam1); 
               if(cx==0)
               {     
                 Imprime_Asc_Hex( p1,128);
                  }
                 else
                  {
                    __delay_ms(20); // on est pas si pressé ce ça
                   }
                  k=FLASH_WriteBlock(L2, p1);
               sprintf(txt," retour k=%5d\r\n",k);
               Print(txt); 
              }
             L1=L1+128; 
           }
           RTS=1;
           CPrint("\r\n Fin de lecture data wave\r\n");
           Etape=4;


je ne vois pas qu' est ce qui coince at 65536, en travaillant avec des uint32_t ?


à TempsX
j'ai testé ton Hex ..OK
quelle est ta derniere adresse flash ?

[satinas]

J'ai testé ton programme, il se plante pareil, arrivé à l'adresse 0x10000.
Pourtant le bootloader série peut écrire sans problème toute la flash, je viens de le tester avec un HEX de test de 128k.
C'est assez inexplicable. Lors des erase ou write page, la cpu est bloquée durant 2ms, peut être quelque chose n'aime pas ça dans ton pogramme, mais pourquoi cela se produit en 0x10000, mystère.
Il faudrait faire un programme plus court qui ne fait que ça.

[Temps-x]

Re

Source du message quelle est ta derniere adresse flash ?

Jusqu’à la fin de la mémoire flash, c'est à dire 1FC00, bon c'est vrai, je triche un peu, car il reste 64 octets qu'on peut utiliser.

Je vais augmenter la taille jusqu'à la fin.

A+

[paulfjujo]

Dans l'option concernant la mémoire rom
On ne peut que mettre un word 16 b
Comment alors mettre › 64ko?

[paulfjujo]

Dans l'option concernant la mémoire rom
On ne peut que mettre un word 16 b
Comment alors mettre › 64ko?


Il doit y avoir une subtilité de XC 8!
Je pense mettre un peu d'asm pour contourner ce problème.
Ou faire une version plus minimaliste.

[satinas]

Pourquoi 16 bits ?
Sur le programme de test du bootloader j'ai 0-1fafb, le bootloader est en fin de flash, le compilateur n'y touche pas.
Il faut faire un petit programme qui écrit toute la flash sans MCC. Je verrai demain, cela m'intrigue.

[Temps-x]

Re

Voila ma dernière version ou on peut lire toute la mémoire programme, j'ai laissé tombé la fonction decfsz qui me poser beaucoup de problème, je l'ai remplacé par une addition 24 bits, avantage la taille réelle est mise dans le début de la chanson (les3 premier octets)

En faisant des essais je m’aperçois qu'on peut utiliser une fréquence beaucoup plus haute que celle de 11050 Hz, dans une seule condition, il faut quelle fasse un multiple de 11050 Hz,

Exemple : ( 11050Hz x 2) = 22100 Hz, ( 11050Hz x 4) = 44200 HZ, ( 11050Hz x 8) = 88400 Hz

L'avantage de prendre une fréquence plus haute son : une lecture sans un très léger sifflement, amélioration de la qualité du son, plus besoin de condensateur, une simple résistance de 2700 ohms suffit avant d'attaquer l'amplification.

On peut comprendre pourquoi le son se trouve amélioré, un ampli base fréquence travaille sur des fréquences allant de 50 Hz à 20000 Hz
et ignoras les fréquences plus haute, comme notre signal va varier en tension, l'ampli va juste amplifier la variation de tension, mais pas la fréquence qui dépasse ses capacités

Ici on est bien en section ASM.....

Fichier code, plus fichier compiler, sortie sur RC1 : SonWavDelay.zip

A+

[satinas]

Bonjour,
Voilà un programme xc8 qui écrit sans problème la flash de 128k, c'est plutôt rapide, 3 secondes.
Je ne vois pas ce qui cloche dans l'autre programme.

Write_flash_18F27K42.c

[paulfjujo]

Bonjour Satinas et TempsX,


a temps X
ta version n'utilise pas l'ecriture en flash par bloc de 128b , puisque les datas y sont déja ...
ni la lecture UART ..
donc no problemo..

à Satinas
je pense que tu definis le maxi à 01FC00 parce que ton Ton programme s'implante en
205 01FEBA
206 ;main.c:
j'ai compilé ton code , renommé en main.c, apres avoir supprimé Memory.c et *.h
charé et excuté le code....
Relu ensuite le contenu du PIC ;
les datas s'implantent bien à partir de 0x80 ....... OK !


c'est OK , mais ne contient pas d'autres fonctionalités.
Je pensais à un probleme coté Realterm ..qui cesserait d'envoyer des données ...
car j'ecris le bloc dans la flash QUE si je reçois un bloc de 128 bytes ..
Ce qui est perturbant c'est cette limite qui tourne autour de 65536
alors que Realterminal n'a envoyé que 65000-16384 données .. donc pas concerné par la valeur 65536.

le probleme semble etre ici
XC8 met du code à cet endroit ! .. ecrabouillé ensuite par le stockage en bloc data wav en flash

0F7A0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
0F7B0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
0F7C0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
0F7D0 0100 0000 0A00 0000 6400 0000 E800 0003
0F7E0 1000 0027 A000 0186 4000 0F42 8000 9896
0F7F0 0000 F5E1 0005 9ACA 013B 0000 1000 0000
0F800 0000 0001 0000 0010 0000 0100 0000 1000
0F810 0000 0000 0001 0000 2010 4155 5452 2031
0F820 6148 6472 6177 6572 5220 3643 543D 2058


Je vais essayer d'utiliser tes fonctions au lieu de celle de MCC Memory.c et Memory.h
dans mon programme , mais avec un environnement tout neuf , sans avoir eu utilisé MCC ...
et ne laissant que l'UART ..necessaire.