When you get ABS NG, NEVER reboot. If there's no bootloader how do you expect rebooting to fix the issue?! We could have tried to fix it otherwise.

Latest version of Utilities (which is v1.3) should have any problem (if any!) solved, so I'm officially out of ideas.

Oh. Bummer. I had some files I wanted to keep on there (LuaZM files mostly). I think I have most of them backed up, so that'll be okay, I guess. Are you sure I can't do anything?

@Spenceboy98

What was the last action you did on your calculator before turning it off (before ABS NG happened)?

Well I had it on Utilities before I turned it off the other day. I turned it on and it was normal. I turned it off again for a few seconds (while still on Utilities), but I wanted to check the time again (to see if I was correct from what I saw) and it just popped up. I exited and checked to see if it would go away if I turned it off and on after using another app, but it was still there. That's when I decided to reset it to see if that would make it go away. Then it wouldn't turn on at all.

And when did you see the ABS NG screen? Did you see it only once or a few times?


Ah okay, that should be it... it's late already...

A quick reminder...

Assuming you were really running v1.3 (launched March 21st) and not v1.2, the source code, corresponding to the part of the add-in that was running, is here: https://github.com/gbl08ma/utilities/blob/v1.3/src/homeGUI.cpp#L38

I had an explanation for the problem as it was happening on calcs with v1.2 and earlier installed, and so I fixed the possible cause in v1.3 - my explanation was that it was because I was attempting to handle Shift+AC manually - it turned out this isn't necessary; for some reason, at an early point in development it was but then it stopped being and this didn't get changed. So PowerOff isn't even called on v1.3. If it still happens with v1.3, then the explanation, assuming the problem has to do with Utilities, "escalates" to GetKeyWait, and in that case I think it's not just Utilities that can cause the problem.
Also note that this is different from other problems (but more or less confirms it's the ABS that gets erased), in that you managed to see the ABS message because the calculator didn't hang on the Casio logo (previous calcs did, and when users rebooted they would not come back, not even to the ABS, which is what makes me thing the ABS is being erased). Unfortunately you ended up rebooting it anyway, and now the only way to know what happened is to use a flash chip reader.
It would be nice if Spence's and/or flyingfisch's dead calculators were sent to someone who can use a flash reader, so we can get dumps. I really want to solve this issue once and for all.

In a related note, in a few days everyone using v1.2 of Utilities should be prompted to update.

Maybe it is not the OS (or Utilities) which is erasing the flash memory... as this is very unlikely to happen "accidentally". Simon never told me about an "ABS NG" screen, so I believe he never saw this when killing two of his Prizm calculators after repeated OS updating procedures. He told me of scorched parts on the PCB instead.

So what happens seems to be that there is a problem with the flash chip or some external components which results in either dying instantly (scorched parts) or always reading 0xFF bytes where no actual erase happened.

I can confirm that the diagnostic mode is entered when those bytes at 0x300 are 0xFF.

I saw it when playing with system timers with handlers set on RS memory (so yes, I was kinda asking for it without knowing). The first sector would read all 0xFF. In that state, one would see the ABS NG screen (really, just the diagnostics screen with ABS NG on top left) every time when resuming from standby. If you connected the USB cable, it would enter "Receiving..." mode automatically, presumably allowing for Protocol 7.00 interaction. Of course rebooting (not before attempting to "update" the OS in order to try fixing it) broke it permanently.

Simon said that a post-mortem ROM dump would be useful.

Then we would know whether the ROM data has been damaged or the ROM itself. And if it's fully functional, then we know that some external PCB component broke.

I've been directed to this thread to post about my two dead Prizms. I had one for just under three years, I believe. Then I decided to mess with the software a bit. Updated to OS 2.00, finally. I had installed Utilities, Tic-Tac-Toe, and OverClui. I hadn't overclocked to extreme amounts and certainly not for extended periods of time. After a period of some inactivity with the calculator, I was about to use it. April 2. it wouldn't turn on. Of course, the first thought was that the batteries were gone, even though the indicator was showing full batteries just a few days ago. The batteries didn't work in a TI-84, that was the problem, right? Replacing the batteries didn't fix it and I started freaking out. I try some of the troubleshooting procedures that Google managed to come up with, even some from this thread. No dice. I didn't quite need the calculator right then, so I did some more important things that night. The next day, it still wouldn't power on, so I took out the batteries and plugged them into the TI-84 again. The new batteries didn't work either so I was really confused. (I think just having them in there drained them; the calculator was powered on but it couldn't do anything). I gave up then and just decided to buy a new one- maybe it just died of old age or something. Plus, the thing was well below $70 on Amazon on April 4. I bit.

Prizm 2. April 9. All is well, the subtle scent of the fresh plastic of the new fx-cg10 is enough to make me feel comfortable again. I stop wondering why the other one died for a while. Updated to OS 2.00 immediately. May 4, I install add-ins. Utilities, and a different set of games. Thinking the oc'ing could've led to the death of the first Prizm, I didn't touch the CPU. All is well. First period on May 6th, I turn on the calculator and show a friend the novelty of having topical games on a calculator. Two hours later, the calculator wouldn't turn on. My heart sank. Whatever course of events that happened a month ago apparently happened within a matter of hours, as attempts to revive the calculator through a variety of means were futile. I survived the AP Calc exam with an emergency fx-9750GII.

Sorry for the essay.

TL;DR: 2 prizm bricks, both had the add-in Utilities, OS 2.00, and were not in use when they died.

What games did you have installed on the second calculator? More specifically, what games did you show your friend?

[deleted]

Also, I forgot to mention, some games automatically OC the CPU on start (and usually underclock it at exit). This is a "feature" I have already argued against some years ago, but nobody paid much attention. So you may have OC'ed the CPU without knowing. It would be good if you could post a list of those games.

Do you know what games have that feature? Also, do you think that Utilities might have contributed to these brickings, or that it was more likely the overclocking issue?

Gravity Duck has that feature (at least some versions of it), and the Flappy Bird port and Ashbad's Rainbow Dash Attack do OC too. There may be other add-ins doing it (I'm not sure about CGDOOM, for example), and with closed-source add-ins it's hard to check, unless the author explicitly mentions it...

There are also some games that (ab)use some sections of RAM other than the add-in stack and heap, like the MPEG 2 player and CGDOOM, and for sure overwriting not-well-known RAM areas like that certainly does no good.

As for your second question, I don't know what to say... every time I discussed this with other people, for instance TeamFX, the final conclusion was that it must have been something else causing the brick/ABS error/hang on shutdown. Some people think the restart circuit is faulty in some hardware revisions at least, for example.

The add-ins I had were Utilities, Flappy Bird, Minesweeper 2, Othello, 2048, Tetrizm, and Rainbow Dash Attack. :v

Also, I don't want to live in a world where it's apparently easier to brick a calculator than an Android device.

OK, so you actually overclocked your calculator.

And yes, it's easier to brick a Prizm than most other embedded devices, especially if you start messing with the system. Unlike other embedded platforms like phones, the Prizm was not designed to run 3rd party software and is not prepared to fail gracefully to a recoverable state when these pieces of software mess up in bad ways. This can be seen on a number of design decisions, for example the fact that add-ins run in privileged mode, the first flash sector (where the one and only bootloader is) not being protected, and the lack of a official SDK for independent developers.

Bummer. Send it in for repair and hope for the best?

I think that would be the most sensible option. If they refuse to repair it, see if you can get it back in its current state, in case we ever find a relatively easy way to recover these dead calculators.

Interesting, as I survived the SAT with my emergency fx-9750GII too.

I am still hoping that at some point a way will be discovered to fix these PRIZM's...


Until then, welcome to the Shattered Prizm club... :-\