TeamFX told me to never press the reset button. He suspects there's a bug in the circuit that does the reset, at least in some hardware revisions. Personally I had no bad experience with the reset button (obviously, in my case, if I pressed reset after the ABS was broken the calculator would stop - as it stopped - working, but that's not fault of the poor button).

flyingfisch wrote:
Hmm... well, I set down my PRIZM (which was off) and the off screen all of a sudden turned on
Strange, looks like a glitch with the interrupt that checks for the AC/On key, possibly combined with some problems with the code that was on RS memory at the time.

Assuming the broken RS memory code didn't erase the first flash sector (like it did with mine...), your calculator would have still been able to boot the ABS, where you could invoke the emergency OS updater. If you can't get to that point, it's either a unrelated hardware problem (perhaps caused by pressing the reset button, adding a problem to the existing problem), or the ABS did indeed get erased (which means you have a brick like mine, and the recovery options are either replacing the flash chip with a new programmed one, which is expensive, or far more easily and realistically replacing the main board).

Some questions:
What was the calculator running when you turned it off?
Was the calculator overclocked?
What software did it have installed (OS version and list of add-ins, with their versions if possible)?
For how long did you have that calculator?
Do you happen to have registered the information that Utilities gives on the "System information" screen?
(this is probably unrelated, but anyway) Do you remember what date and time the RTC was set to?

EDIT:
TeamFX just sent me this in an email, regarding this case:
TeamFX wrote:
Well, it is probably not a hardware issue (or let's see how long the fx-CP400 will survive). It seems to me that there are some software bugs and these seem to only affect "power users" who install a lot of stuff. Knowing that there is a USB bug that sometimes crashes the calculator when replacing a file with the same name, it appears that the USB mass storage implementation might cause these issues. Overwriting memory that is not meant to be overwritten. But I'm somehow giving up on this. I can only give you guys the following hint: Try to reduce the number of Windows connections. Another reason could be the overclocking stuff which I would also recommend not to use at all.

Explaining the sudden device turn on could have several reasons. I know that the calculator sometimes doesn't turn off until you press another key. Maybe putting the device on the desk resulted in a small vibration generating an AC/on key interrupt or something similar. And the shutdown screen could have been displayed because of not finishing the last shutdown correctly or because the OS detected some hardware error and (tried to) shut down immediately. We will never know.
So after some talking with Nathan Austin about the situation, he sent me this email.

Quote:


If you've not yet sent in your unit, could you send it to me instead?

Nathan Austin
2122 N 3rd Street
Washougal, WA 98671

I'll pass it along to R&D and they'll take a closer look. (and, of course, we'll get you a replacement)

Thanks,
Nathan


Sounds hopeful Smile
Great, this is exactly what I hoped that could happen: have this kind of problem go through some more technical circles at Casio other than just customer support, which probably, for all this time, has just been trowing problematic units in the trash.
gbl08ma wrote:
Great, this is exactly what I hoped that could happen: have this kind of problem go through some more technical circles at Casio other than just customer support, which probably, for all this time, has just been trowing problematic units in the trash.


Yeah, that's why I decided to talk to Mr. Austin instead of contacting customer support. Also, I found him a lot more helpful than customer support in the past, so I definitely recommend US people talking to him if you have problems. Wink
Got my new prizm back today, going to check out the board model and stuff with Utilities.

Utilities system info:

Code:

OS: CASIOWIN
OS Version: 01.02.0000
OS date: 2010.1122.2053
PCB Model: 755A
Calc Model: fx-CG 10
Real HW: Yes
ABS: CASIOABS
ABS date: 2010.0916.0917
CPU PVR: 10300B00
CPU PRR: 00002C00
CPU CVR: 43440110
Device ID: soQJELhT
I just got the new calculator today. After using it for a few minutes, I turned it off and set it down. A few minutes later I came back and noticed that the screen was on, with just the casio logo showing. Instead of pressing the reset button, I popped out a battery. After replacing the battery the calculator did not turn back on.

Maybe its utilities (that was the only thing I had on it at the time.)?

Also, should I tell Casio that I had Utilities on it?
Are you serious? You put Utilities onto your Prizm and it died? Did you try all the key combos to start the boot code emergency OS update?

Well, if it's true, then... this can't be a coincidence... so I have to contact gbl08ma and this add-in file shall be removed instantly from the servers.
That seems to be what happened...

EDIT:

and none of the key combos work.

This is the copy of utilities i was using: https://dl.dropboxusercontent.com/u/63621708/calcs/utilities.g3a


I think it was version 2014.0104.2200 because these are the first few bytes:


Code:

AA AC BD AF 90 88 9A 8D D3 FF FE FF FE FF 12 FE FF FD 96 53 9B 00 00 00 00 00 00 00 00 00 00 00 00 D9 C6 E1 01 01 00 00 00 00 00 00 00 00 00 01 F9 A8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 74 69 6C 69 74 69 65 73 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 69 AC 40 55 54 49 4C 49 54 49 45 00 00 55 74 69 6C 69 74 69 65 73 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 74 69 6C 69 74 69 65 73 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 74 69 6C 69 74 69 65 73 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 74 69 6C 69 74 69 65 73 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 74 69 6C 69 74 69 65 73 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 74 69 6C 69 74 69 65 73 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 74 69 6C 69 74 69 65 73 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 74 69 6C 69 74 69 65 73 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30 31 2E 30 30 2E 30 30 30 30 00 00 32 30 31 34 2E 30 31 30 34 2E 32 32 30 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 74 69 6C 69 74 69 65 73 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 74 69 6C 69 74 69 65 73 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 74 69 6C 69 74 69 65 73 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 74 69 6C 69 74 69 65 73 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 74 69 6C 69 74 69 65 73



Code:

ª¬½¯ˆšÓÿþÿþÿþÿý–S›            ÙÆá         ù¨              Utilities                    i¬@UTILITIE  Utilities               Utilities               Utilities               Utilities               Utilities               Utilities               Utilities               Utilities                    01.00.0000  2014.0104.2200                                      Utilities                           Utilities                           Utilities                           Utilities                           Utilities
Source code for all versions, including the ones of versions I only sent to beta testers (because every revision is logged), are on GitHub ( https://github.com/gbl08ma/utilities ). You can find out the version (with commit hash) from the About screen, or by looking at the strings with a hex editor (thank god I implemented such a good versioning system). I never sent anyone a "dirty" build, i.e. one that is not based on a clean git commit. Additionally, the exact build time is stamped on the g3a header by mkg3a (as you already saw). The builds need a libfxcg fork I have and which is probably not updated online, but in case anyone's interested right now I can just zip and upload it.

I too find it very strange that the problem of dead calculators only seems to happen / happens more frequently on calculators with Utilities (or other custom add-ins). At the same time, it only happens on certain calculators (never happened on mine, never happened on more than half a dozen calculators with Utilities installed). While it's true that Utilities is probably not used as much on these calculators as flyinfisch, etc. use it, if it had something to do with usage time, it would not break on the very same day that Utilities is installed!
On the other hand, anyone who knows probabilities can tell that if it's a random event, it has a constant chance of happening at any time (or in other words, flyingfisch may just have been "unlucky" and me and all my friends have been "lucky", but for how long will that luck remain?)...

In fact, I was the first one to write about my suspicion that the problem may have something to do with Utilities, but the users were the first to dismiss me. So I kept investigating (no conclusions so far) but never said anything more (other than in a few emails I exchanged with TeamFX). Only thing I could come up with, has to do with the way the MCS is accessed not just on Utilities, but on all custom add-ins (because AFAIK we only know about the syscalls Utilities uses, so there's not much choice).

Downloads of Utilities and other software of mine from my server are temporarily suspended. About Cemetech and etc. I could start bothering people, but I'd rather not spend more time and start figuring out which build is that, right now.
This is a log of the conversation that went on in IRC:
#cemetech wrote:
[Wednesday, October 23, 2013] [09:27:33 AM] <gbl08ma_> ah, because I already know how my Prizm broke (Simon explained). If you want to know, drop me a line.
[Wednesday, October 23, 2013] [09:27:38 AM] <KermM> a, I think my best one was about 800 t-states
[Wednesday, October 23, 2013] [09:27:46 AM] <saxjax> (C) [Xeda112358] yes, Z80
[Wednesday, October 23, 2013] [09:27:51 AM] <KermM> gbl08ma_: I presume you don't want to post it publicly?
[Wednesday, October 23, 2013] [09:28:06 AM] <saxjax> (C) [Xeda112358] this is unrolled, too
[Wednesday, October 23, 2013] [09:28:18 AM] <gbl08ma_> KermM: well, it can become a rather long explanation
[Wednesday, October 23, 2013] [09:28:25 AM] <benryves> LuxenD: I just love coffee ice cream. And liqueur. And chocolates. Just not coffee.
[Wednesday, October 23, 2013] [09:28:26 AM] <saxjax> (C) [Xeda112358] but the rolled version is <750
[Wednesday, October 23, 2013] [09:28:57 AM] <gbl08ma_> basically, I had copied code to the RS memory which I thoguht was not used. Turns out it was used when powering off, and retained the flash read/write routines.
[Wednesday, October 23, 2013] [09:29:27 AM] <saxjax> (C) [LuxenD] flavor & smell of coffee is bad, but i really needed yhe energy this morning.
[Wednesday, October 23, 2013] [09:29:36 AM] <gbl08ma_> at some time, I got lucky enough to have the Prizmed Framework timer calling that portion of RS memory by the time the flash erasing routine was still there
[Wednesday, October 23, 2013] [09:29:50 AM] <gbl08ma_> and it erased the first flash sector, which as it turns out, is not protected.
[Wednesday, October 23, 2013] [09:29:56 AM] <KermM> gbl08ma_: Got it, makes sense.
[Wednesday, October 23, 2013] [09:30:09 AM] <gbl08ma_> so in conclsion, RS memory is "do not touch".
[Wednesday, October 23, 2013] [09:30:15 AM] <KermM> It's too bad no one is working on a custom OS; the fact that the bootloader sector is not protected is pretty interesting
[Wednesday, October 23, 2013] [09:30:38 AM] <gbl08ma_> I need to revert my linker scripts and crt0.S to what they were before this thing.
[Wednesday, October 23, 2013] [09:31:02 AM] <gbl08ma_> otherwise, each add-in I compile is a danger to any calc it runs on.
[Wednesday, October 23, 2013] [09:31:08 AM] <saxjax> (C) [LuxenD] what, for the prizm?
[Wednesday, October 23, 2013] [09:31:18 AM] <AHelper0> I thought I posted that
[Wednesday, October 23, 2013] [09:31:28 AM] <saxjax> (C) [LuxenD] heh, i need a new coded software project, but i dont yet have that calculator.
[Wednesday, October 23, 2013] [09:31:28 AM] <AHelper0> "Also, the RS memory shouldn't be touched as it is the memory used for bringing the calc into and out of sleep since it persists even when off."
[Wednesday, October 23, 2013] [09:31:39 AM] <AHelper0> Posted in the IL/RS memory topic Wink
[Wednesday, October 23, 2013] [09:31:46 AM] <gbl08ma_> The Prizm startup process is simple, when the CPU turns on it jumps to 0x80000000 and executes whatever is there.
[Wednesday, October 23, 2013] [09:32:07 AM] <gbl08ma_> on my broken calc, lots of 0xFF was what was there.
[Wednesday, October 23, 2013] [09:32:49 AM] <gbl08ma_> any kind of custom OS should not try to use the first boot sector, but instead make itself look like a normal OS to the bootloader.
[Wednesday, October 23, 2013] [09:33:14 AM] <gbl08ma_> that way, the emergency OS updater will probably still work.
[Wednesday, October 23, 2013] [09:33:46 AM] <gbl08ma_> and the bootloader will probably still boot the OS as long as the checksums and special strings are correct.
[Wednesday, October 23, 2013] [09:34:21 AM] <gbl08ma_> and now I got to go studying some subject where I don't use the calculator. Sad
[Wednesday, October 23, 2013] [09:34:23 AM] <gbl08ma_> bye.
[Wednesday, October 23, 2013] [09:34:48 AM] <saxjax> (C) [hellninjas] Bye :<
[Wednesday, October 23, 2013] [09:35:09 AM] <saxjax> (C) [LuxenD] what subject could that be? i seem to find a use for my calc in everyclass
[Wednesday, October 23, 2013] [09:35:09 AM] <saxjax> (C) [LuxenD] DocDE7++
[Wednesday, October 23, 2013] [09:35:22 AM] <AHelper0> Sad http://www.cemetech.net/forum/viewtopic.php?p=188052#188052
I would like to get this very clear: no public version of any of my add-ins ever touches the RS memory, and the same is true for all builds of Utilities I sent to my beta testers.

This is the PM (with reply) I sent flyingfish along with a link to download that build:
flyingfisch wrote:
gbl08ma wrote:
Hi!

Here's a new build of Utilities for you to try, 156 commits ahead of v1.1:
http://s.lowendshare.com/0/1388775914.845.utilities.g3a

Don't forget to rename to "utilities.g3a". Make sure to not mix it with the v1.1 binary as the file size is basically the same despite all the additions (yes, Utilities went on a diet).

I'd like to brief you on all of the new features, but the truth is that I can't really remember how many things I've added and fixed. (I'll have to go through the logs when I write the readme).
Some of the news I remember include a feature for trimming (deleting parts of) the calendar database, a new calendar look (you probably saw screenshots already), a way to import events from a iCalendar file (needs desktop software which I'll publish soon), kind of a text editor (single-line editing for now, sorry), and many many GUI changes, some more noticeable than others.

Another very important thing I need you to test is the file copying function. It is no longer an "advanced tool" as I managed to fix it, and it should now be very stable.

Please report any problems, especially those related to the file copying function. Thanks!


Everything is working extremely well for me Smile

Of the additions of that build, the file copying function is the only one that could eventually cause problems, but I don't think flyingfisch has copied files on his new-but-now-broken calculator.
As long as you used one of the recent builds, I am pretty sure gbl08ma removed anything that might be dangerous. And you hadn't overclocked it, we can also allay TeamFX's suspicions there. Wink

Edit: As per IRC, I see you and gbl08ma seem to have this under control.
So, the verdict is that it wasn't Utilities?
flyingfisch, is this a repair model that you've got with both electrolytic capacitors missing? Simon guesses it's still the internal voltage supply that is failing. Missing capacitors could maybe accelerate this.

But I believe it could also be some incorrect interface definition. Just imagine you forgot to pass a pointer onto the stack that is written to or imagine there is a parameter defined as int, but it is actually a pointer...
As these add-ins run in privileged mode (or you would call it, they run as root) you can effectively destroy anything.

Blame Casio for not providing a public SDK or making add-ins run in user mode.
My repaired calculator with missing capacitors is still running fine, and definitely did not break in the first hour. I am using NiMH batteries in it, in case it has any relation.

It's interesting that you think it was not Utilities, because during the night I came up with a theory that may very well explain everything the people with dead Prizms have experienced, and traces all the fault to Utilities. I only started thinking of this, when it became very obvious that the problem had to do with timers, as flyingfisch's calculator turned on on its own not once, but twice, with a different main board each time.

It all starts when people turn off the calculators while the home screen or chronometer of Utilities is running. These screens use GetKeyWait_OS instead of GetKey, and I believe GetKeyWait installs and uses some timers, most likely system timers (1-4) to know when to check for keyboard input.
GetKeyWait_OS doesn't handle the power off key sequence, so I handle it myself by manually calling PowerOff(1);
Now, it is possible that GetKeyWait doesn't stop its timer when I do this, as it is a system timer. There's also a timer (eventually the same) to check for the backlight and auto-power-off timeouts; these are system timers and probably GetKey turns them off before calling PowerOff(1). So I mean that the stopping and uninstalling of these timers is done by GetKey and not by PowerOff(1); it would be good if someone could check this by disassembling these functions...

My theory basically is, that since Utilities calls PowerOff manually, it may not stop all the timers. So the timers keep running when the CPU is in standby mode (assuming that is possible). The auto-power-off timer keeps running, and after 10 minutes or so, its handler decides that it's time to power off the calculator - but there's a problem, the calculator is turned off already. Somehow the CPU wakes up (this is the hardest part to reason about, IMO) and starts the power off routine, the one that saves things to flash and displays the Casio logo. But there's a problem: the flash areas where the things should go, are already used because the calculator was already turned off. In all this confusion, the state-saving routine ends up overwriting the wrong flash areas, damaging the boot area. One never gets to see the "ABS NG" message, because the calculator hanged on the Casio logo screen, and no matter if users pull a battery or press the reset button, the ABS is no longer there to boot the system. And this is my most coherent theory on how one starts with a perfect Prizm and ends up with a brick. Please comment, maybe I'm extrapolating too much.

This whole thing is very easy to verify... just turn off the calculator while on the clock screen of Utilities, wait half an hour, turn on the calculator; rinse and repeat until it is broken. If I were a millionaire I would buy a bunch of Prizms just to do this, but I'm not... and the only emulator we have doesn't emulate the standby mode.

Utilities also does something most other add-ins (and definitely, all of Casio's add-ins) don't do: on most start-ups, the first keyboard-reading routine it executes is GetKeyWait, and not GetKey. In fact, GetKey might not even be executed before powering off: if users open Utilities, and turn the calculator off right after, GetKey will never be called before powering off (please note, on the current source code it is no longer like this, as I have added a Keyboard_PutKeyCode followed by a GetKey call before powering off, in an attempt to solve an unrelated issue:

Code:
            SetSetupSetting( (unsigned int)0x14, 0);
            DisplayStatusArea();
            // make sure GetKey (and thus, the whole "multitasking"/power/setup system) "gets" the fact that we have disabled Shift,
            // otherwise Shift may still be enabled when resuming from standby:
            int gkey;
            Keyboard_PutKeycode( -1, -1, KEY_CTRL_EXIT);
            GetKey(&gkey);
            PowerOff(1);
            SetSetupSetting( (unsigned int)0x14, 0);
            DisplayStatusArea();

On the build flyingfisch had (or better, on all the public builds), that code is the following:

Code:
            SetSetupSetting( (unsigned int)0x14, 0);
            DisplayStatusArea();
            PowerOff(1);
            SetSetupSetting( (unsigned int)0x14, 0);
            DisplayStatusArea();

... and this code did not remove the Shift modifier despite the multiple SetSetupSetting attempts, so I added the GetKey thing in an attempt to fix it (not yet tested).

So, for now, don't turn off the calculator while Utilities is running (that is, if you must absolutely use it). Luckily enough, I have stopped doing this on my calculator ever since it was repaired - my idea was that nothing wrong could happen if I exited out of Utilities and went to Run-Mat before turning off, and this gave me peace of mind - but if this theory is right, it turns out that I was actually preventing a disaster from happening.
so, I already sent Nathan Austin this on Friday (the day it happened):

Quote:

Hi Nathan,

I just got the new calculator today. After using it for a few minutes, I turned it off and set it down. A few minutes later I came back and noticed that the screen was on, with just the casio logo showing. Instead of pressing the reset button, I popped out a battery. After replacing the battery the calculator did not turn back on.


Considering the updates since then, should I follow up and let him know that a third-party addin caused the crash, and if so, should I tell him which one it was?
flyingfisch wrote:
Considering the updates since then, should I follow up and let him know that a third-party addin caused the crash, and if so, should I tell him which one it was?


If they really wanted to know, a simple Google search would have told them...
It might be unrelated to Utilities.g3a and Simon still believes it is because of a weak hardware design. He did some repeated OS flashing (using the official updaters) recently and reported that the reset circuit seems to be problematic. Sometimes the OS hanged, sometimes it was difficult to start the emergency updater. He assumes that this Prizm is going to die soon.

So let Casio know about this, but don't tell them that you _think_ it happened because of a faulty (and custom) add-in. They shall pay some experienced technician to have a look at the PCB of these dead Prizms.
A problematic reset circuit doesn't explain how the calculators turn themselves on (and to make things worse, show the Casio logo screen instead of resuming normally), even if it explains why the calculators never come back after users take off the batteries and put them back in.

I'm resuming downloads of Utilities and the Eigenmath port from my servers. Specifically in the case of Eigenmath: it, for sure, isn't responsible for any damage, because even if it's not a hardware problem but is related to PowerOff(), there's no way it can happen with Eigenmath, as it doesn't use GetKeyWait_OS or PowerOff; it doesn't write to RS memory* either, and only touches the MCS when users invoke specific commands when it is running as a strip.
As for Utilities, in over 1000 downloads I find too strange that "only" three calculators (four if we take into account the fact that flyingfisch's has had two) have died, and that the problem is so hard to understand and reproduce. Anyway, I will continue to watch out for situations like this, and I will eventually change some more things in Utilities, related to the use of the PowerOff syscall so that no matter if that's the cause or not, it gives me some peace of mind.

I will also keep working to make my software as stable as possible, so that users don't have to reboot the calculators in the event of system errors (it's not like that still happens frequently, but anyway). And I will try to avoid changing batteries as much as possible - which is incompatible with the fact that, apparently, the only way to keep the Prizm from bricking, is to never reboot or turn it off.

And since we're letting Casio know they should hire better HW engineers, we may as well suggest that they start putting the bootloader in a mask ROM. I have a Casio digital diary from 1990 which has all its software in a mask ROM, and it has survived multiple improper reboots, improper hardware poking (by me) and lots of years of usage. Non-upgradeable for sure, but its software has no bugs (and it's not like Casio updates the ABS on their calculators often). Funnily enough, my Prizm from 2010 already had to be replaced, and flyingfisch's calculator had to be replaced not once, but twice. Oh, the irony.

* I actually lied when I said Utilities didn't touch the RS memory: it does, but for a very well-defined simple thing and to change a single byte - the one corresponding to the color of the function keys. Nothing more.
Yeah, the sudden OS startup also confuses me a bit. But if some internal IC breaks (or is worn), anything could happen. Any add-in timers shouldn't automatically turn on the device if you called PowerOff(). Yet, I don't know if this is also true for system timers. It may depend on the standby mode level that is entered.

flyingfisch, what type of batteries are you using?
You could also try the following:
(assuming the RESTART circuit is dead)

- Open your Prizm and put some conductive material on the contact labeled "3" to automatically boot into emergency OS update mode, or put it on contact "1" to automatically start the diagnostic mode
- As far as I know, you just have to press [AC/ON] to enable this and no RESTART button is involved
- It may not work for the first try, so make sure that the conductive material is clean and fully attached to the test contact
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
» Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8  Next
» View previous topic :: View next topic  
Page 4 of 8
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement