Protocol 7.00 - Error 0x04 and tests
28 posts
• Page 1 of 3 • 1, 2, 3
- cakeisalie5
- Senior Member
- Posts: 101
- Joined: Sun Mar 27, 2016 10:24 am
- Location: France
- Calculators: Casio Afx 1.0, Casio fx-9860GII, Casio fx-CG50
Protocol 7.00 - Error 0x04 and tests
Hello,
I create this topic because I'm out of ideas for this. In fact, since I want to manage OS Update/Receive Mode/unimplemented commands, devices error et al., the many meanings of error 0x04 annoy me.
I want to distinguish the cases where the device doesn't exist (fls0 on fx-9750GII doesn't exist, crd0 on fx-9860GII doesn't exist) and where the command is unimplemented (because of protocol impoverishment or OS Update/Receive mode confusion), without using a lookup table if possible. How could I do this ? Is there a way to know if we are in OS Update/Receive mode, or to check if a device exists on the calculator ?
(I also wanted to get a way to check if file existed without getting it, so I can implement file overwriting confirmation missing (to me) for file copying, but send command with systematic no-response to overwrite request should make it)
I create this topic because I'm out of ideas for this. In fact, since I want to manage OS Update/Receive Mode/unimplemented commands, devices error et al., the many meanings of error 0x04 annoy me.
I want to distinguish the cases where the device doesn't exist (fls0 on fx-9750GII doesn't exist, crd0 on fx-9860GII doesn't exist) and where the command is unimplemented (because of protocol impoverishment or OS Update/Receive mode confusion), without using a lookup table if possible. How could I do this ? Is there a way to know if we are in OS Update/Receive mode, or to check if a device exists on the calculator ?
(I also wanted to get a way to check if file existed without getting it, so I can implement file overwriting confirmation missing (to me) for file copying, but send command with systematic no-response to overwrite request should make it)
Part of the Planète Casio community (FR) - main author of Cahute
- SimonLothar
- Senior Member
- Posts: 605
- Joined: Sat Sep 15, 2012 6:59 am
- Location: Krautland ****
- Calculators: Casio fx-7400GII, Casio fx-7400GII (SH4), Casio fx-9750GII, Casio fx-9750GII (SH4), Casio fx-9860G, Casio fx-9860G SD, Casio fx-9860G Slim, Casio fx-9860GII SD, Casio fx-9860GII SD Power Graphic 2, Casio Classpad 330 plus, Casio fx-CG20, Casio fx-CG50, Casio Classpad fx-CP400
Re: Protocol 7.00 - Error 0x04 and tests
There are different communication environments:
F. i.
the bootcode OS updater,
the OS updater inside the OS,
the standard OS's communication dialog
and then some.
Each of the different communication environments offer a specific set of protocol 7.00 function, which furthermore differ between the calculator types and OSes.
The functions, which I experienced as fairly reliable ones since 2008 and with every calculator I own, are ST:1, ST:7 and ST:0x56, provided you invoke the bootcode OS updater.
But that does not mean, that you can get these functions work correctly in any situation. Some newer environments need ST:2 or ST:0xA or special device control commands, too.
Additionally the order of commands, even the timing can have a meaning.
Any violation of these - sometimes very hidden - rules can lead to error 0x04 or timeouts.
Protocol 7.00 is only consistent up to a certein level. Do not expect too much.
Especially since the GII-calculators ocurred, they constantly changed things around protocol 7.00.
If you enter the world of protocol 7.00, you enter a world of hurt.
F. i.
the bootcode OS updater,
the OS updater inside the OS,
the standard OS's communication dialog
and then some.
Each of the different communication environments offer a specific set of protocol 7.00 function, which furthermore differ between the calculator types and OSes.
The functions, which I experienced as fairly reliable ones since 2008 and with every calculator I own, are ST:1, ST:7 and ST:0x56, provided you invoke the bootcode OS updater.
But that does not mean, that you can get these functions work correctly in any situation. Some newer environments need ST:2 or ST:0xA or special device control commands, too.
Additionally the order of commands, even the timing can have a meaning.
Any violation of these - sometimes very hidden - rules can lead to error 0x04 or timeouts.
Protocol 7.00 is only consistent up to a certein level. Do not expect too much.
Especially since the GII-calculators ocurred, they constantly changed things around protocol 7.00.
If you enter the world of protocol 7.00, you enter a world of hurt.
I'll be back!
- cakeisalie5
- Senior Member
- Posts: 101
- Joined: Sun Mar 27, 2016 10:24 am
- Location: France
- Calculators: Casio Afx 1.0, Casio fx-9860GII, Casio fx-CG50
Re: Protocol 7.00 - Error 0x04 and tests
Nice ending sentence ! ^^
But as I've started free-ing this domain, I might as well continue, so that other people don't have to suffer this much.
I didn't know there were two OS update environments, what is the difference between the two ? And how can you distinguish them using the extended ack for example ? (it looks like ProductID and Username are wiped out for OS Update, OS versions are different (00.16.35 - 00 for OS Update, 02.05.34 for Receive Mode) and HardwareID are different (Gy363000 for OS Update, Gy363007 for Receive Mode) but I don't know about these being constant among several calculators)
Have you got the cases where 0x02 is required (and what args are expected) ?
Also, speaking of command 0xA, there are a few commands I couldn't find description of in the fxReverse project documentation (all versions) and fx_calculators_SuperH_based.chm (online version on taricorp (version 15, I think) and downloadable version on this website (version 20)). These include commands between 0x04 and 0x1F included, commands referred to as "OS Update-related" in the fxReverse documentation project (even if some have been mentionned by TeamFX here), and what you refer to as "special device control commands". Have you got a more complete list of commands somewhere ?
But as I've started free-ing this domain, I might as well continue, so that other people don't have to suffer this much.
I didn't know there were two OS update environments, what is the difference between the two ? And how can you distinguish them using the extended ack for example ? (it looks like ProductID and Username are wiped out for OS Update, OS versions are different (00.16.35 - 00 for OS Update, 02.05.34 for Receive Mode) and HardwareID are different (Gy363000 for OS Update, Gy363007 for Receive Mode) but I don't know about these being constant among several calculators)
Have you got the cases where 0x02 is required (and what args are expected) ?
Also, speaking of command 0xA, there are a few commands I couldn't find description of in the fxReverse project documentation (all versions) and fx_calculators_SuperH_based.chm (online version on taricorp (version 15, I think) and downloadable version on this website (version 20)). These include commands between 0x04 and 0x1F included, commands referred to as "OS Update-related" in the fxReverse documentation project (even if some have been mentionned by TeamFX here), and what you refer to as "special device control commands". Have you got a more complete list of commands somewhere ?
Part of the Planète Casio community (FR) - main author of Cahute
- SimonLothar
- Senior Member
- Posts: 605
- Joined: Sat Sep 15, 2012 6:59 am
- Location: Krautland ****
- Calculators: Casio fx-7400GII, Casio fx-7400GII (SH4), Casio fx-9750GII, Casio fx-9750GII (SH4), Casio fx-9860G, Casio fx-9860G SD, Casio fx-9860G Slim, Casio fx-9860GII SD, Casio fx-9860GII SD Power Graphic 2, Casio Classpad 330 plus, Casio fx-CG20, Casio fx-CG50, Casio Classpad fx-CP400
Re: Protocol 7.00 - Error 0x04 and tests
I try to answer your questions one by one.
ST:0xA seems to return an ack-ST:00-packet only with fx-CG-calculators. Perhaps to identify a fx-CG.
fxReverse Chapter 4 (communication protocol) has been written about 10 years ago. Manuel Naranjo and Andreas Bertheussen analyzed the FA-124 data-flow. F. i. function 0xA did not exist in the OSes, which they investigated. After I joined the team in 2008, we did not raise the subject of the protocol 7.00 again. We concentrated on syscalls. Hence the changes in the last update, which Andreas Bertheussen released in 2010, related to this topic.cakeisalie5 wrote:Also, speaking of command 0xA, there are a few commands I couldn't find description of in the fxReverse project documentation (all versions)
Some time ago "Some people" asked me, not to publish any OS update related information in fx_calculators_SuperH_based.chm. I kept this promise up to now. I looks, as if this is not necessary any more. I'll ponder, if I can include some additional information in release 21. But do not expect too much. I do not have any official documentation. I obtain my information chiefly by reading OSes. That is time-consuming and tiresome. The single function related to OS update I ever used is ST:0x56. Though, as far as I am concerned, this is by far the most important and powerful protocol 7.00 function.cakeisalie5 wrote:Also, speaking of command 0xA, there are a few commands I couldn't find description of in fx_calculators_SuperH_based.chm (online version on taricorp (version 15, I think) and downloadable version on this website (version 20))
ST:0xA seems to return an ack-ST:00-packet only with fx-CG-calculators. Perhaps to identify a fx-CG.
I'll be back!
- SimonLothar
- Senior Member
- Posts: 605
- Joined: Sat Sep 15, 2012 6:59 am
- Location: Krautland ****
- Calculators: Casio fx-7400GII, Casio fx-7400GII (SH4), Casio fx-9750GII, Casio fx-9750GII (SH4), Casio fx-9860G, Casio fx-9860G SD, Casio fx-9860G Slim, Casio fx-9860GII SD, Casio fx-9860GII SD Power Graphic 2, Casio Classpad 330 plus, Casio fx-CG20, Casio fx-CG50, Casio Classpad fx-CP400
Re: Protocol 7.00 - Error 0x04 and tests
ST:2 is only of value with the serial interface. The fx-7400GII exclusively uses this interface. On the fx-CG I did not manage to access the mass store device by an external program at first. The serial interface has been a valuable loophole.cakeisalie5 wrote:Have you got the cases where 0x02 is required (and what args are expected) ?
If you have to transport a lot of data via protocol 7.00, a switch to 115200 baud is sensible.
The args are as described in fxReverse (Chapter 4.3.2... "02" Set link settings).
I only used "9600" and "115200". But I'd say "19200", "38400" and "57600" should work as well. At least in Prizm OS 1.04 and fx-9860 OS 1.03, I saw, that ST:02 supports this set of baudrates.
I'll be back!
- cakeisalie5
- Senior Member
- Posts: 101
- Joined: Sun Mar 27, 2016 10:24 am
- Location: France
- Calculators: Casio Afx 1.0, Casio fx-9860GII, Casio fx-CG50
Re: Protocol 7.00 - Error 0x04 and tests
I'll wait for the next version of the chm then !
What about the differences between OS Updates, and how to identify the distant environment ? And about commands supported by each environment (I have the global idea, but detail would be appreciated to make up a lookup table and if a command is supported) ? Will it be in version 21 ? ^^
What about the differences between OS Updates, and how to identify the distant environment ? And about commands supported by each environment (I have the global idea, but detail would be appreciated to make up a lookup table and if a command is supported) ? Will it be in version 21 ? ^^
Part of the Planète Casio community (FR) - main author of Cahute
Re: Protocol 7.00 - Error 0x04 and tests
Well, Simon, you may release that information as long as this is not "actively" promoted.
The fx-CP400, fx-FD10 Pro, fx-9750GII and fx-7400GII only allow code execution via the OS update commands and we do not know what Casio is planning for new models.
The fx-CP400, fx-FD10 Pro, fx-9750GII and fx-7400GII only allow code execution via the OS update commands and we do not know what Casio is planning for new models.
- SimonLothar
- Senior Member
- Posts: 605
- Joined: Sat Sep 15, 2012 6:59 am
- Location: Krautland ****
- Calculators: Casio fx-7400GII, Casio fx-7400GII (SH4), Casio fx-9750GII, Casio fx-9750GII (SH4), Casio fx-9860G, Casio fx-9860G SD, Casio fx-9860G Slim, Casio fx-9860GII SD, Casio fx-9860GII SD Power Graphic 2, Casio Classpad 330 plus, Casio fx-CG20, Casio fx-CG50, Casio Classpad fx-CP400
Re: Protocol 7.00 - Error 0x04 and tests
I attached a draft of the page. It is too early to release a complete new version of the help file. I am still analyzing OSes and checking my findings with a test-program in different environments.cakeisalie5 wrote:I have the global idea, but detail would be appreciated to make up a lookup table and if a command is supported
I'll be back!
- cakeisalie5
- Senior Member
- Posts: 101
- Joined: Sun Mar 27, 2016 10:24 am
- Location: France
- Calculators: Casio Afx 1.0, Casio fx-9860GII, Casio fx-CG50
Re: Protocol 7.00 - Error 0x04 and tests
Yay ! I'll start working with that and the model list then
By "Verification (OS update)" (answered by an ack), do you mean before 0x56, we should send command 0x07 and get the ack ?
By "Verification (OS update)" (answered by an ack), do you mean before 0x56, we should send command 0x07 and get the ack ?
Part of the Planète Casio community (FR) - main author of Cahute
- SimonLothar
- Senior Member
- Posts: 605
- Joined: Sat Sep 15, 2012 6:59 am
- Location: Krautland ****
- Calculators: Casio fx-7400GII, Casio fx-7400GII (SH4), Casio fx-9750GII, Casio fx-9750GII (SH4), Casio fx-9860G, Casio fx-9860G SD, Casio fx-9860G Slim, Casio fx-9860GII SD, Casio fx-9860GII SD Power Graphic 2, Casio Classpad 330 plus, Casio fx-CG20, Casio fx-CG50, Casio Classpad fx-CP400
Re: Protocol 7.00 - Error 0x04 and tests
In the course of a regular OS update, some packets are sent before 0x56 starts. F. i. on a fx-CG first there is a T:5 ST:00 packet, then T:1 ST:0x07, then T:1 ST:0x0A, then T:1 ST:0x06 to set the link timeout to 10 minutes and after that T:1 ST:0x56 starts. But this is only an example. There is no unique way across the different types and years. And things are more complicated with the mass storage device of fx-CG and fx-CP. These interfaces have to be properly setup via some DeviceIOControl-commands. Especially in the late years they changed things more often.cakeisalie5 wrote:By "Verification (OS update)" (answered by an ack), do you mean before 0x56, we should send command 0x07 and get the ack ?
I think the only way out is to log and consider the data-tranfer during an OS update.
Concerning 0x56:
This I found somewhere in my docs (the RAM addresses mentioned are examples for fx-9860 calculators; the available RAM ranges, you could use, are different on newer types):
upload and run
Command: 0x01 '56' '1' <upload-size> <load address> <start address> <checksum> 0x00
<upload-size> is the eight byte ASCII-HEX representation of the amount of data to be uploaded.
<load address> is the eight byte ASCII-HEX representation of the RAM-address where the data has to be loaded to (fx-9860 OS update: "88030000").
<start address> is the eight byte ASCII-HEX representation of the start address, where to jump after successful upload (fx-9860 OS update: "88030000").
Contrary to other commands, this one is terminated with a binary zero.
The data are transported with standard data-packets of subtype "56".
The last data-packet is acknowledged with an ack-packet of subtype "03"! The uploaded program is started automatically after successful transfer of the last data-packet.
The uploaded program mustn't return (rts). It has to reboot, after it has done its job.
The uploaded program is not limited to one 64k-sector. In case of calculators with 512k RAM it may extent up to address 0x8807FFFF. As well it may start at 0x88024000, because the heap is not used in this process. Hence the maximum size of the program may be 368k.
---
I generally use the bootcode OS updater as environment for 0x56. 0x56 is the only way out I know to run any self written program on a fx-CP400. But as far as I am concerned, it is only useful for experimental purposes.
I'll be back!
28 posts
• Page 1 of 3 • 1, 2, 3
Return to Calculator Hacking/Modding Discussions
Who is online
Users browsing this forum: No registered users and 3 guests