34s builds 1249 and 1250 crash on real hardware

[Gene Wright]

I know builds are often handoffs between you guys, but just an FYI.

Both the 1249 and 1250 builds "crash".

When I run a program, the screen blanks and sits there. When I press ON, it displays "Restored"

[Walter B]

Thanks for the feedback. We'll look into it. Emulator build 1250 seems to work as usual :-)

Walter

[Marcus von Cube, Germany]

Gene I was suspecting this. Testing will start tomorrow. Have you cleared the calculator or are you trying to run what has been in the calculator before? Does the crash depend on the program you are trying to run?

[Gene Wright]

1) It cleared the calculator when I loaded the new firmware. Erased was displayed and memory was empty.

2) It does not matter what program is run. LBL A, +, GTO A does the same thing as a longer program.

3) When it displays "Erased" is the calculator really totally erased? Any other way to clear it completely in case some bit is floating somewhere it should not be?

and... no problem on the testing. That's what I was doing. Beta software testers have to be willing to run into problems. That's our job! :-)

[Etienne Victoria]

Same thing here with 1249 (obtained via SVN client.

However, I forgot to Erase prior but had nothing saved in Flash.

However, new operation yields errors such as:

1 2* 2* 2* 2* 2* 2* 2* 2* 2 * gives 512 --> Correct

2 * gives 100 --> Not correct

Along with very slow keyboard response including prefix keys.

Will retry after full erase as I did not follow the procedure correctly.

Etienne

[Paul Dale]

Hmmm, I just tried these exact steps and running a short looping program and neither failed on 1249 for me. However, what you are seeing is quite a bit like what I saw immediately after upgrading (and also like something I saw last week running much older firmware).

I changed the batteries and the problems went away. It would be quite a surprise if this is the cause of three people experiencing failures within a day of each other but it might be worth a try. BATT indicated 2.9 with the old batteries which should be fine.

We'll still investigate since it seems unlikely that this is the root cause.

- Pauli

[Gene Wright]

More info:

LBL A, +, GTO A

will work fine if you single-step through the program. Push R/S however and it goes off to la-la land.

AND

BATT indicates 2.7 on my unit. Hmm...

Edited: 18 July 2011, 5:41 p.m.

[Gene Wright]

So, moral of the story... 2.7 BATT went to la la land, 3.1 batt runs.

[Marcus von Cube, Germany]

It looks like 40 MHz is too demanding. The next revision will run at about 15% less speed. I had increased the speed considerably, especially for "non crystallized" machines, in order to get good baud rate divisor values. This might have been too much for some devices.

[Gene Wright]

Any way to set the speed value by the user?

[Marcus von Cube, Germany]

You can set test mode (ON+1) which emulates a low battery situation. This will set the speed to one third of what you have now.

[Jim Yohe]

I seem to remember a discussion about what the proper voltage and someone (Marcus?) said he programmed the 34s to show a low battery warning at a level different than the 30b.

Perhaps that level needs to be looked at once again to determine when it actually should show the warning so these failures don't show up unexpectedly.

[Marcus von Cube, Germany]

The maximum speed was simply set too high. I'd be glad if someone will test with the most recent build and some worn out batteries.

I'll check back here tomorrow...

[fhub]

Another question:

Does the emulator also emulate the speed of the real calculator, or does it always run with the maximum speed depending on the PC?

Edited: 18 July 2011, 6:38 p.m.

[Marcus von Cube, Germany]

The emulator is just a native C program which does not have an idea of the speed of the ARM processor. So it runs as fast as it can.

[fhub]

Quote:

---

The emulator is just a native C program ...

---

Ahhh, so it's rather a simulator than an emulator, correct?

(I thought it may work like some other emulators which emulate the CPU and then run the original ROM code).

And how do you then get the calculator ROM (calc.bin)?

Do you write it in original ARM code or is there just a cross-compiler (C to ARM) in the HP20b-SDK which creates this ROM?

Edited: 19 July 2011, 6:14 a.m.

[Marcus von Cube, Germany]

I've two separate environments:

Microsoft Visual Studio for the emulator.

Eclipse with the Yagarto GCC cross compiler and some Unixish tools.

The command line version compiles nicely under Linux or Mac OS with the compilers provided there.

The project is just a collection of source files which may be compiled (with some conditional compilation inside) into the various incarnations of the software. It took some time to get all the right pieces together. ;-)