HP Forums

Full Version: Bad Flash in HP Prime
You're currently viewing a stripped down version of our content. View the full version with proper formatting.

I ran the internal tests via [ON][SYMB] + [F][C][O] during the warmstart and got this for the Evaluation Test - CHK BAD FLASH:

                CHECK END.
CHIP 0 BAD BLK SUM: 7 & BAD BLK :
0 1 650 672 990 1546 1875

Should I be thinking about getting an exchange?

I am now stuck with only access to the current App -- the Function App. Any time I hit my Apps key, it resets the calculator.

Edit: the only means of recovery was to format the flash chip using the warm-boot tools


Edited: 26 Sept 2013, 10:29 p.m.

How did you do that? Formatting the flash chip?

Also, F+C+O during on+symb doesn't do anything for me. Do you need to press the keys together or in sequence? Thanks!

Quote:
How did you do that? Formatting the flash chip?

Also, F+C+O during on+symb doesn't do anything for me. Do you need to press the keys together or in sequence? Thanks!


As soon as you press and release ON+SYMB (simultaneously or in sequence; doesn't matter), hold down F, C, and O (simultaneously or in sequence; doesn't matter but should be done relatively quickly -- hold it down for about 2 seconds)

After holding down F, C, and O (during the warmstart obtained from pressing ON+SYMB) you will be given a menu. Press 4 (FLS Utility), and then press 3 (Format Disk C). This clears out the flash. Once finished, press ESC to back out into the main menu. From there press 9 (RESET) or you can alternatively press ON+SYMB

OK thanks so much . . .you need to be very quick when pressing FCO (and while the screen is still dark).

In the evaluation menu, I also get a NG (No good?) result (as opposed to OK) for check bad flash. I'm wondering if that is normal.

Quote:
OK thanks so much . . .you need to be very quick when pressing FCO (and while the screen is still dark).

In the evaluation menu, I also get a NG (No good?) result (as opposed to OK) for check bad flash. I'm wondering if that is normal.


I was asking that question sort of tongue-in-cheek. The reality is that there will always be a few portions of flash memory that is "no good" even right off of the production line. It's likely industry-wide accepted that some percentage of bad sectors is perfectly "normal." Similarly, products with LCD screens often come with disclaimers that one or two pixels being "flaky" is completely normal. As long as the number of bad blocks isn't too large (in my case it appears there are 7 of them), you're probably fine.

That said, don't take my word for it. Having paid over $100 for this, I would want mine to have absolutely no bad blocks. The other numbers probably refer to the actual location of the bad block.

Agree.

Regarding the EDITMAT and EDITLIST crashes, I can't believe that the beta testers (and according to TW, he had a few) never used these commands.

The Prime does have a future, though - - overall, I like it (just wish that CAS commands could also be executed in RPN syntax).

Had more then a few. Issue basically came down to this particular case (using a user created variable) was missed.

To give you an idea of the size of things in the system, your binary is about 12mb when the font is removed. That is about the size of windows 3.1.

TW

Looks like they may have also overlooked computing sums consisting of more than 1,000 entries. This bug probably related to the list size limit "bug."

No problem Tim - - I understand that some things get overlooked, and I appreciate all of your hard work - - it is just that EDITMAT and EDITLIST are built-in commands, and of course you would expect a user to call these with user-created variables - - that was one of the first things I did (duh!).

Keep it up! No doubt that these issues can get resolved, and all will be well.

Well, that really is the crux of things. One person's "first thing" is in many cases the majority's "never will attempt". :-)

TW

Point well taken.

Please also remember the issue with EIGENVV (the list prodiced by that command can't get recalled after storing in built-in lists L0, ..., L9, without crashing).

Again, this may not be a priority, but it would be nice to work at some point in the future, nevertheless.