Strange issue with KEY GTO

Post here to share useful tips and tricks, to ask questions about using your DM42 or to report software-related problems
dlachieze
Posts: 137
Joined: Thu May 04, 2017 10:20 am
Location: France

Strange issue with KEY GTO

Post by dlachieze » Mon Feb 12, 2018 10:49 pm

I'm working on a program that doesn't work as expected and I've been able to relate the issue to the handling of calls to a sub-routine including a menu with KEY GTO instructions.

Here is a short test program to reproduce the issue. Note that this issue occurs only on the DM42 (with both firmware 3.2 and 3.3 - I've not tested with the previous ones). I cannot reproduce the issue with the latest version of Free42 (2.0.14) nor with the HP-42S.

Code: Select all

00 { 47-Byte Prgm }
01▸LBL "TST"
02 CLST
03 XEQ "KG"
04 8
05 RTN
06▸LBL "KG"
07▸LBL A
08 "ADD"
09 KEY 1 GTO 01
10 KEY 9 GTO 99
11 MENU
12 PROMPT
13 GTO A
14▸LBL 01
15 GTO A
16▸LBL 99
17 END
When you execute TST, it clears the stack, calls KG and put 8 on the stack. KG displays a menu with an ADD soft key. If you press ADD nothing is put on the stack and if you press EXIT it should return to TST.

Now: XEQ "TST" EXIT => you get on the stack 8 in X and 0 in the other registers as expected
But if you press the "ADD" softkey before pressing EXIT you have on the stack 8 in X and Y and 0 in Z and T
and if you press "ADD" twice before pressing EXIT you get on the stack 8 in X, Y and Z and 0 in T

I don't understand why there is one more 8 on the stack for each press of the "ADD" soft key ????

It seems that there is a bug in the return address stack handling.
If I put a STOP just after the 8 at step 4 and do XEQ "TST" ADD EXIT the program stops on the STOP instruction with 8 in X, then if I do SST twice, upon the RTN it goes back to step 4 and put again 8 on the stack as if the return address from the XEQ "KG" was not consumed by the step 17, or was duplicated by pressing ADD.
tst.zip
(198 Bytes) Downloaded 23 times
DM42 SN: 00425

Thomas Okken
Posts: 484
Joined: Tue May 02, 2017 3:48 pm
Location: New Jersey, USA
Contact:

Re: Strange issue with KEY GTO

Post by Thomas Okken » Mon Feb 12, 2018 11:19 pm

I can't reproduce that on my DM42 (fw 3.2).

dlachieze
Posts: 137
Joined: Thu May 04, 2017 10:20 am
Location: France

Re: Strange issue with KEY GTO

Post by dlachieze » Tue Feb 13, 2018 6:07 am

This is weird. I saved my test program as a .raw file (the one I attached above), and I also saved the complete state of the DM42 (attached below).

If I remove the TST program with CLP and reload it from the .raw file, it works as expected, no more issues.

If I reload the complete state the issue is back, so this seems to be related to some corruption in the DM42 memory, which has survived the back button reset done after upgrading from 3.2 to 3.3. This will need some investigation from the SwissMicros team when they will be back from vacation.

Thomas, can you check with the state file below and confirm you can reproduce the problem? (don't forget to save your current state before loading the tst state)

tst.s42.zip
(2.05 KiB) Downloaded 21 times
DM42 SN: 00425

Krauts In Space
Posts: 85
Joined: Wed Jan 03, 2018 2:48 pm
Location: Nuremberg, Germany

Re: Strange issue with KEY GTO

Post by Krauts In Space » Tue Feb 13, 2018 8:45 am

Deleted
DM15L S/# 10584 FW v25
DM42 S/# 01015 FW v3.5

Thomas Okken
Posts: 484
Joined: Tue May 02, 2017 3:48 pm
Location: New Jersey, USA
Contact:

Re: Strange issue with KEY GTO

Post by Thomas Okken » Tue Feb 13, 2018 1:39 pm

dlachieze wrote:
Tue Feb 13, 2018 6:07 am
Thomas, can you check with the state file below and confirm you can reproduce the problem? (don't forget to save your current state before loading the tst state)

tst.s42.zip
I could look at this, and maybe I will do so tonight (EST), but assuming (1) I can reproduce it and (2) it's not just a typo in the TST program, debugging this would be up to SwissMicros.

dlachieze
Posts: 137
Joined: Thu May 04, 2017 10:20 am
Location: France

Re: Strange issue with KEY GTO

Post by dlachieze » Tue Feb 13, 2018 4:52 pm

Thanks Thomas if you can look into this. I agree, the debugging should be on SwissMicros side, however it would be good to have confirmation that the issue is not just with my own unit but can be reproduced on other units using the state file. I've looked again on my TST program and I don't think there is any typo in it but I may have missed something obvious.
DM42 SN: 00425

Thomas Okken
Posts: 484
Joined: Tue May 02, 2017 3:48 pm
Location: New Jersey, USA
Contact:

Re: Strange issue with KEY GTO

Post by Thomas Okken » Tue Feb 13, 2018 6:31 pm

dlachieze wrote:
Tue Feb 13, 2018 4:52 pm
Thanks Thomas if you can look into this. I agree, the debugging should be on SwissMicros side, however it would be good to have confirmation that the issue is not just with my own unit but can be reproduced on other units using the state file. I've looked again on my TST program and I don't think there is any typo in it but I may have missed something obvious.
Problem confirmed, with Didier's state file.

I tried inserting a R/S between LBL 99 and the END, and after XEQ "TST" [ADD] [EXIT] and stepping from there, I could see it return twice to the line after the XEQ "TKG" (XEQ "KG" in the listing posted in this thread), which suggests that somehow the top item on the return stack got duplicated.

Or something like that... This really looks like something for SwissMicros to debug.

(UPDATE) Note that I'm not necessarily claiming that this is a DM42 bug; it could be a Free42 bug that just happens to manifest here for some reason. The reason SwissMicros will have to debug this is that they are the only ones who have the DM42 development system.

Wherever the fault may prove to be, I'm very interested what it is! When XEQ is performed from the keyboard, it clears the subroutine stack (meaning, it resets the subroutine stack pointer), so even starting from a weird state file, it's hard to see how the return stack pointer could be incremented twice when the test program performs only one XEQ itself. *headscratch*

grsbanks
Posts: 703
Joined: Tue Apr 25, 2017 9:23 am
Location: Preston, Lancs, UK

Re: Strange issue with KEY GTO

Post by grsbanks » Tue Feb 13, 2018 8:59 pm

I've put this on David's radar.

He's working on something else at the moment then he's taking a short break, but he is aware of this and will investigate as soon as he can.
Not SwissMicros staff, just an enthusiast.

Thomas Okken
Posts: 484
Joined: Tue May 02, 2017 3:48 pm
Location: New Jersey, USA
Contact:

Re: Strange issue with KEY GTO

Post by Thomas Okken » Wed Feb 28, 2018 1:31 am

David told me that the problem with Didier's state file is that one of the GTO A instructions has an incorrect cached target. (Local GTO and XEQ instructions remember the location of their destination LBL, so they don't have to search for that label every time.)

So far, it is a mystery how such an incorrect target could occur. When programs are edited, these cached targets are cleared, so they should never be invalid.

I'm tempted to blame the DM42, since I have never heard of this type of malfunction in Free42, but on the other hand, it's not clear to me how the DM42 could mess this up, since this is functionality that exists deep inside Free42, where I would expect it to not be affected by the DM42 patches.

This needs to be looked into, but at least there is a workaround for when this happens: make an edit, any edit, to the affected program and then reverse that edit. Say, insert ENTER anywhere, and then delete it. This will clear all the local GTO/XEQ targets and leave the program otherwise unchanged.

This is not a fix, of course. Bad jump targets should never happen.

dlachieze
Posts: 137
Joined: Thu May 04, 2017 10:20 am
Location: France

Re: Strange issue with KEY GTO

Post by dlachieze » Wed Feb 28, 2018 4:50 am

Thomas Okken wrote:
Wed Feb 28, 2018 1:31 am
David told me that the problem with Didier's state file is that one of the GTO A instructions has an incorrect cached target. (Local GTO and XEQ instructions remember the location of their destination LBL, so they don't have to search for that label every time.)
That's interesting, if the GTO A target at step 15 is step 01 instead of step 07, then each time we press ADD it executes a XEQ "TKG" adding another return address to the return stack which explains the issue.
Thomas Okken wrote:
Wed Feb 28, 2018 1:31 am
So far, it is a mystery how such an incorrect target could occur. When programs are edited, these cached targets are cleared, so they should never be invalid.
So inserting a R/S between LBL 99 and the END as you did above should have cleared the cached targets, but it didn't ....
Thomas Okken wrote:
Wed Feb 28, 2018 1:31 am
This needs to be looked into, but at least there is a workaround for when this happens: make an edit, any edit, to the affected program and then reverse that edit. Say, insert ENTER anywhere, and then delete it. This will clear all the local GTO/XEQ targets and leave the program otherwise unchanged.
I've tried this workaround but it didn't work, I still have the same issue.
Thomas Okken wrote:
Wed Feb 28, 2018 1:31 am
This is not a fix, of course. Bad jump targets should never happen.
Has David also investigated the KEY XEQ issue I've posted here with the associated state file? Is it also related to a bad cached target?
Last edited by dlachieze on Wed Feb 28, 2018 5:20 am, edited 1 time in total.
DM42 SN: 00425

Post Reply