Quelques questions pour guider tes recherches (suit les numéros) :
1) Quelle version des logiciels utilises-tu ? fxRemote ou pfxRecover ?
- pfxRecover
5
- fxRemote
2
2) Quelle étape ne fonctionne pas ?
- Backup Flash
3
- Recover Flash
4
3) Théoriquement, tu n'as pas besoin de faire de backup. Il y en a de partout sur le site. 
4) As-tu fait la manip' pour la mettre en mode "OS Error" (pour le mode "Recover Flash") ?
- Oui
6
- Non
7
5) Commence par installer fxRemote disponible ici puis réessaye. Si ça ne marche toujours pas,
2
6) As-tu vérifié à bien prendre un OS de même version que celui de ta G35+USB ? La version de l'OS se trouve dans le menu "Système" -> [F4]. Si votre OS est du type 02.0
0.**** ou 02.0
1.****, prenez une version 02.0
1.****. Si c'est un 02.0
2.****, prenez un 02.0
2.****. Attention, un OS contenant le mot "slim" n'est pas pour vous, il s'adresse aux anglophones possédant
ce modèle. Si vous l'installez, vous aurez surement tout un tas de bugs !
- Oui
8
- Non
9
7) Met la calto en mode "OS Error". Pour cela, suis les étapes suivantes :
- Appuie sur "Restart" (avec un stylo par exemple) au dos de ta calto (NB: ça n'efface rien du tout dans la mémoire)
- Tout en appuyant sur "Restart", appuie en même temps sur "F2" - "4" - "Ac/ON"
- Relâche le bouton "Restart", mais garde pressés les autres.
- Relâche tout, et successivement, appuie sur "9" puis "X" (au dessus du "+").
Puis
10
8) Je t'invite à laisser un message sur le forum, ton cas me parait désespéré. Fais attention à bien décrire ton problème (erreur, etc.)
9) Prend le bon OS. Si tu ne sais pas comment ça marche, un OS 02.01.2020 correspond à un fichier OS_02_01_2020_SH3.fls.
Puis recommence la manipulation (à partir de Recover Flash)
10) Le message "OS Error, please update OS" s'affiche-t-il à l'écran de ta Casio ?
- Oui : branche ta casio à l'ordinateur, lance fxRemote, puis fait "Recover". Si tu as toujours un problème,
6
- Non : Recommence la manipulation du 7.
- Cela fait 3-4 fois que je refais la manip', mais je n'obtient toujours rien : courage, tu va y arriver. Essaye d'allonger un peu les temps entre l'appui sur les touches. Inutile de se presser
Citer : Posté le 16/03/2016 23:36 | #
OS 2.05 writes exam mode information to addresses 0x250016 or 0x260016. This is within the MCS backup area (0x250000..0x26FFFF). No MCS data is backed up during exam mode. Press RESTART and your data is gone.
Possible values:
0xFF: exam mode off
0x95: exam mode on (French mode)
0x05: exam mode on (12h expiration)
In fxRemote, enable the setting "Recover Main Memory Backup Area" to overwrite the MCS area.
Ensure that the new data is either empty or does not have exam mode information included.
Prizm OS 2.02 may also store some exam information in the MCS backup.
Additionally, extra data is stored starting at address 0xB20000.
This is a new writable area within the OS image (0x20000..0xB5FFFF).
Citer : Posté le 16/03/2016 23:37 | #
Enlève moi d'un doute, flasher l'OS ne flash pas les 4 Mio non ? Les programmes sont sauvegardés en général. Donc le ME pourrait être dans le coin.
Ajouté le 16/03/2016 à 23:38 :
Ah bah merci Teamfx
So… Thanks Teamfx
Citer : Posté le 17/03/2016 13:42 | #
But 0x250016 is supposed to be in P0 space, right ? Where does it physically reside ?
And it's right, OS recovery only erases 2.5 Mio of memory space.
Citer : Posté le 17/03/2016 22:16 | #
No, this is only a flash memory offset (0..0x3FFFFF).
Otherwise it would be virtual address space.
The upper three address bits define the address translation.
To read from the MCS area, use addresses 0xA0250000..0xA026FFFF (uncached access - slow) or 0x80250000..0x8026FFFF (cached access - fast).
In fxRemote, enable the setting "Delete storage memory" to erase the storage area.
Citer : Posté le 18/03/2016 12:39 | #
I see. Does exam mode allows add-in execution ? In this case, we could possibly overwrite some memory areas, right ? There should be a way if the system does it for storage memory access or OS recovery. (I haven't found anything in the documentation, if you've got anything please share a link
By the way, what is MCS exactly ? I've seen it everywhere in the documentation but no research could help me find out what it is.
Citer : Posté le 18/03/2016 15:18 | #
I see. Does exam mode allows add-in execution ?
No add-in can be run in exam mode, not even official add-ins from Casio (Physium, Geometry...).
Diagnostics menu cannot be accessed in exam mode either (you get the exam mode popup instead of the diagnostics popup when turning on the calculator while holding the required keys).
You might be able to reset the MCS with a computer, which is not a problem - exam regulations authorities require that the exam mode cannot be disabled from the calculator itself.
You're supposed to be able to exit exam mode by sending any data from another compatible calculator which is not in exam mode.
The micro SD interface is able to send some compatible data (list of card files as a text-program) to the calculator by pressing its button.
I don't know why, but it works when the latest Graph 25+E/35+E/75+E are not in exam mode, and you get a link error when they are in exam mode.
So the Casio exam mode looks secure.
Citer : Posté le 18/03/2016 15:38 | #
Some exam mode documentation begins at page 8:
http://support.casio.com/fr/manual/004/GRAPH75+E_35+E_25+E_Soft_FR.pdf
MCS is the Casio-internal term for the 64 KB of main memory data that can be viewed in the memory manager. Actual RAM size is 512 KB on GII models. MCS could stand for Memory Core System. Early fx-9860G OSes 1.00 up to 1.02 did not save MCS data to the flash chip. If you removed the batteries, then all your data was lost.
Citer : Posté le 20/03/2016 11:02 | #
Ok, so you really can't do anything while in exam mode.
So MCS only covers the main memory. Do you know a way to write directly in the ROM area without calling Bfile ?
Citer : Posté le 20/03/2016 11:56 | #
This is what I have found in some older Insight.g1a source code:
SYSCALL 01C8, _i_Flash_Read
SYSCALL 01C9, _i_Flash_Write
SYSCALL 01CA, _i_Flash_EraseSector
void i_Flash_EraseSector( int sector ); // refer to the flash chip manual
void i_Flash_Write( int address, char*buffer, int count );
void i_Flash_Read( int source, void*target, int count );
I did not use them so far.
+++ Erasing or overwriting the boot area will destroy your calculator! +++
CAUTION: These routines must not overwrite themselves!
Citer : Posté le 20/03/2016 12:00 | #
Thanks, this may be useful to us
+++ Erasing or overwriting the boot area will destroy your calculator! +++
According to the CPU documentation, this area is just at 0xa0000000. Is it right ?
Is there actually a possibility of accidently overwriting the boot area if you know where it is located ?
By the way, in write() and read() (I believe we won't use erase()
Edit : Don't worry, we ain't going to use them randomly. I'm not even sure we will use them at all, not if it is safer to edit to OS save on the computer
Citer : Posté le 20/03/2016 14:25 | #
The boot area resides at addresses 0xA0000000..0xA000FFFF or 0x80000000..0x8000FFFF
Yet, there are shadow areas and writing to them may also kill the boot code.
Areas like: 0xA0400000..0xA040FFFF, 0xA0800000..0xA080FFFF, 0xA0C00000..0xA0C0FFFF, ...
If you are not careful enough, a stupid programming error will kill it!
READ: source is probably the flash read address, target the buffer to save the result and count the number of bytes to read.
WRITE: address is probably the flash write address, buffer the buffer to hold the write data and count the number of bytes to write.
ERASE: sector is probably the flash sector number to be erased.
+++ Be careful with low sector numbers because of the boot area! +++
CAUTION: These routines must not overwrite themselves!
Flash writing and reading is done bytewise, but erasing is always done sectorwise.
One sector appears to be 64 KB in size, but some chip areas may have different sector sizes.
Reading doesn't require a special syscall. E.g., you can use "*(unsigned long *)0xA0000000" to read the first four bytes of boot code.
Flash writing can only change binary '1's to '0's, so continuous overwriting will end up with all bits being '0's.
Meaningful flash writing therefore requires a preceding sector erase which changes all '0's to '1's.
Citer : Posté le 20/03/2016 14:36 | #
Yet, there are shadow areas and writing to them may also kill the boot code.
Areas like: 0xA0400000..0xA040FFFF, 0xA0800000..0xA080FFFF, 0xA0C00000..0xA0C0FFFF, ...
Ok, just hearing that tells me I'm not going to use them.
If you are not careful enough, a stupid programming error will kill it!
Still, you could add the security that fits each version of the operating system but I understand the risks
+++ Be careful with low sector numbers because of the boot area! +++
Yup, I'm not using the sector erase syscall anyway.
Reading doesn't require a special syscall. E.g., you can use "*(unsigned long *)0xA0000000" to read the first four bytes of boot code.
So what is the read syscall for ?
Flash writing can only change binary '1's to '0's, so continuous overwriting will end up with all bits being '0's.
Meaningful flash writing therefore requires a preceding sector erase which changes all '0's to '1's.
I should have read more documentation about the flash memory.
Citer : Posté le 20/03/2016 14:59 | #
For code clarity I guess.
Flash writing and erasing is more complicated:
This requires commands (binary patterns) to be written to special flash addresses in a specific order.
Also, all interrupts should be disabled during write/erase access.
Citer : Posté le 20/03/2016 15:02 | #
Thanks for all this information
One last thing : I believe Kristaba had written an experimental driver for the storage memory that bypassed Bfile. Does this mean he had to use those syscalls ?
Citer : Posté le 20/03/2016 15:28 | #
A read-only storage memory program might be possible if you know some parts of the file system structure or maybe some RAM file table. But writing files without Bfile syscalls would require low-level flash erase/write routines and the understanding of the entire file system characteristics.
Citer : Posté le 20/03/2016 15:32 | #
I'm pretty sure he could read and write files. I'll have a look at his sources if I can find them.
Citer : Posté le 20/03/2016 16:16 | #
I just remembered another important issue when it comes to flash writing:
The write/erase routines must not overwrite themselves!
Starting with fx-9860G OS 1.03 or 1.04, there is a copy of the flash write/erase routines stored in some CPU on-chip memory (SH-3: 0xA5600000, SH-4A: 0xFD800000). I don't know the exact addresses right now, but some disassembling should reveal them easily.
vivi28 Invité
Citer : Posté le 01/10/2016 15:19 | #
bonjours tout le monde,
voila mon problème, j'ai une graph 85 en 2.01 et je veut la mettre en 2.04 le soucis c'est que une fois avoir fini de charger l'image que j'ai trouver sur internet dans la calculatrice, elle redémarre mais est toujours en version 2.01 et je ne vois pas ou est le problème.
Si vous avez une solution je suis preneur
Citer : Posté le 01/10/2016 16:00 | #
Comme indiqué en gros, en gras, en couleur en haut de ce sujet, il n'est plus à jour. Je te conseille donc de lire la version à jour : http://www.planet-casio.com/Fr/forums/topic13930-1-Ameliore_ta_Graph_35+_USB_E_en_Graph_75(+E)_!.html
vivi28 Invité
Citer : Posté le 01/10/2016 21:41 | #
en faite j'ai suivi la procédure au lien plus haut mais j'ai posté ma question la car j'ai vue qu'il y avait beaucoup de page de question, du coup je la repose sur l'autre page ?
Citer : Posté le 01/10/2016 21:42 | #
C'est mieux. L'image 2.04, tu es sûr que c'est une image pour SH3 ? La Graph 85 est SH3 quoi qu'il arrive.