Pb écriture en Flash - Page 1

Voila, j'ai une adresse en Flash à laquelle je souhaite écrire, qui est dans la partie normalement autorisée (c'est à l'intérieur d'une variable que j'ai créé moi-même)
L'adrese est dans debut_part_27...
Je comprend pas : l'adresse est bien celle que je veux, mais ça me fait une adress Error...
Si quelqu'un pouvait m'aider... ça serait cool

Je précise que je ne peux pas désarchiver la variable pr mettre la donnée dedans...


short to_write = 'P';
FL_write(&to_write, debut_part_27, sizeof(short));

// Et debut_part_27 correspond à l'adresse 0x005bdbbd (je le sais, ça, c bon), qui est dans la partie OK de la Flash... (c'est dans une variable, qui est en Flash)
// C'est déclaré comme ça : unsigned char *debut_part_27
// Et le FL_write me fou une adresse error... (même pas récupérée par preOS )
// En sachant que je veux écrire 'P' à l'adresse correspondant à debut_part_27


merci !

je pense que le probleme viens de sizeof(short)

essaye avec (long)sizeof(short) a la place

nEUrOne> ça me fait pareil avec le cast

sinon, j'ai fait gaffe à l'ordre des paramètres, qui est inverse de celui pour memcpy (au début, y'avait ça qui foirait, mais c corrigé depuis pas mal de temps)

Au fait, je teste sur VTI avec une ROM 2.05 de 92+, sous PreOS0.56, pas de TSR ni de Maxmem

squale92, Je trouve qu'ils sont assez explicite les msg d'erreurs de l'OS. 0x005bdbbd ça a une belle tête d'adresse impaire
Et le crash ne peut pas être récupéré par PreOS, les vecteurs d'interruptions sont toujours ceux de l'OS pendant que la flash est déprotégée.

oopsss... le truc d'écrire à des erreurs impaires
merde, j'avais gravement pas pensé à ce pb là J'y fait gaffe qd j'écrit en RAM... mais en ROM, j'avais pas pensé à ça
Bon, v retenter, en magouillant pour obtenir une adresse paire...

merci !

Bon, alors, j'essaye à l'adresse paire immémdiatement apèrs, soit 0x005bdbbe
là, plus de plntage (c déjà ça )... mais qd je mate à cette adresse avec l'éditeur hexa (hexview, de PCT), je constate que rienne s'est passé : mes octets à cette adresse ne sont pas affectés (ils valent la même chose que avant modification )

je vois po trop pkoi...
j'ai peut-être encore fait une grose bétise ?

ExtendeD> la flash est déprotégée meême pr écrire dans les zone utilisateur ?

Oui, on ne peut écrire uniquement que mot par mot en flash.
On peut quand même considérer ça comme un bug de l'AMS, ça ne coûte pas cher de tester si l'adresse est vraiment paire, et de quitter si ce n'est pas le cas.
Il faudrait rajouter dans la doc de tigcclib que l'adresse doit être paire.

rajouter pr que l'adresse soit parire, c bon, je l'ai fait.
(suffit d'un petit modulo 2 pr tester )

[edit] suppression de quelques chose qui n'avait pas sa plec ici, et qui ne change rien au topic

OK...

[EDIT] suppression de quelque chose qui n'avait pas sa place ici, et qui ne change rien au topic

---

erf, oué, ça serait dommage que quelqu'un en profite...


Kevin> tu ne saurai pas pkoi ça ne m'écrit rien maintenant ds la var ?
(ça plnate plus, mais ça n'altére pas les octets )

Tu stockes 0x005bdbbd dans debut_part_27 de quelle façon ?
Ca vient de là à mon avis.

je commence par chercher le pointeur de type SYM_ENTRY correspondant à la variable.
ensuite, je cherche la fin de celle-ci (l'adresse de l'octet suivant la variable) en additionnant à l'adresse de début la taille de la vairbale (+2 par rapport à ce qui est donné par les 2 premiers octets de la variable)

puis j'obtient le début de la portion où je veux écroire en soustrayant un certain nombre d'octets correspond à la somme des tailles du marqueur de fin de fichier, et du bloc dont je dispose.
(ici, je recule de 53 octets)

puis, je regarde si debut_part_27 est paire.
si elle ne n'est pas, je fait debut_part_27++, pour passer à l'adresse paire suivante

ainsi, j'arrive à avoir debut_part_27 == 0x5BDBDE

Bon, alors squale92, nettoie tes posts. Mais ça changera pas grand chose je pense.

squale92 a écrit :
je constate que rienne s'est passé : mes octets à cette adresse ne sont pas affectés (ils valent la même chose que avant modification )

je vois po trop pkoi...
j'ai peut-être encore fait une grose bétise ?

parce que tu ne peux ecrire en rom que sur un endroit.... VIERGE..... (là ou y'a des 0xFF quoi)
et oui...pas de chance, hein ?

(en fait tout ce que tu peux faire, c modifier l'etat des bits de 1 vers 0.
donc s'il y 0x79, tu peux qd meme ecrire 0x39 par ex)

Arf...
On peut écrire que qd c'est à 0xFF
J'avais tout mis à 0x00...
Bon, pas grave alors, je peux mettre à 0xFF à l'origine, qd je crée le fichier (je le crée sur le PC).

Par contre, y'a pas moyen de remettre à 0xFF une fois que c'est, par exemple, à 0x51 ou quelque choise comme ça ?
(histoire de pouvoir réécrire une fois qu'on a déjà écrit ?)

d'apres ce que je sais, tu es obligé d'effacer tout le segment de 64ko d'un coup..
et c meme + possible sur 2.0x..
(em_blockerase est suprimé.)

arf
merde alors
parce que là, ça aurait été super pratique pr enregistrer les records dans la variable que j'utilises comme archive pr mes graphismes
y'a pas moyen de "tricher" ?

j av déjà pensé pour les records.
j'av meme créé un topic
pour "tricher", je sais pas, demande à ExtendeD

OK. parce que, de toute façon, pr KII, il me faut :
- le fichier PPG
- e fichier d'archive avc les graphs
- le lancuer PPG (j'en utilises pas, mais bon)
=> ça fait déjà 3 fichiers

et, en plus, il me faut :
- records
- sauvegarde
soit un ou deux fichiers en plus...
alors, j'aimerai intégrer ça dans le fichier d'archive...
qd celui-ci est en RAM, j'ai pas de pb... mais, en règle générale, il est en archive (pr économiser de la RAM, donc, je ne peut pas le sésarchiver)

squale92 a écrit :
arf
merde alors
parce que là, ça aurait été super pratique pr enregistrer les records dans la variable que j'utilises comme archive pr mes graphismes y'a pas moyen de "tricher" ?

Certainement. EM_blockErase doit encore traîner quelque part, même s'il n'est plus exporté.
Mais ce que tu es censé faire, c'est de copier ton fichier en RAM, d'effacer le bloc en archive avec EM_abandon, d'éditer ton fichier en RAM, et de le réarchiver à un endroit vierge trouvé avec EM_findEmptySlot.

arf, ça me force à désarchiver et réarchiver alors

Ça use moins la FlashROM qu'un EM_blockErase, et ça prend aussi moins de RAM (seulement la taille du fichier à sauvegarder temporairement, pas 64 KO pour le bloc entier).

OK.
donc, si y'à po moyen de faire la mnipulation directe sur les quelques octets que je veux altérer, je penses que je tenterai ça.
J'aurai assez de RAM pr la taille du fichier (ça, c certain, ou presque)

par contre, est-ce qu'il y a un risque que ça lance un Garbarge collection ?
(je préfèrerai éviter d'avoir une boite de dialogue qui s'ouvre qd j'ai les interruptions désactivées...)

S'il n'y a plus de ROM libre, EM_findEmptySlot te renverra NULL, et tu devras appeler EM_GC manuellement. Mais tu peux lui passer un paramètre pour qu'il n'affiche pas de dialogue. Cf. documentation de TIGCC.

OK. Ct pr savoir s'il fallait ou non appeller la ROM_CALL de garbage manuellement iou non.
merci !

je teste ça ce WE.
(sauf si j'arrive à faire tourner TIGCC à l'IUT... la dernière fois, j'en avais chié avec les .bat sous NT)

c vraiment pas propre comme méthode, je suis contre
ça va savater la rom à force

argh...
de toute façon, vu que si je fait une variable autre pr ça, je l'archiverai...
enfin...

Je pense pas que ca fasse grand chose, d'archiver souvent. Je programme souvent sous SIDE on-calc avec des sources archivées. Le fichier est réarchivé à chaque sauvegarde, et il n'y a aucun problème (sauf quand side se rate au GC parfois et pomme la source, mais ça ne vient que de side, ce bug).