So many axevsm errors that don't error on the programming editor

[Technical]

Please see post 39. No more testing will be carried out on these files.

 

[tiscando]

No more testing will be carried out on these files.

Is it only because I had an out-of-date dsn before post #39?
I tried to make it simpler by not just posting the dsn and code, but also typing up a simple step-by-step procedure about how to discover that the code stops at "gosub audatab0 '##########*****FAULT*****##########".

Did you at least run the code in the .dsn to discover that it terminates with "...access violation in module axevsm1.dll"?

 

[tiscando]

How about the big picture as well?

I have just collected data of the errors in my large programs, which traces the chasing fault in axevsm1.dll, here:

[U]Program name                             | Picaxe | Length | Line                       | Address | What it does wrong at this line and address[/U]
KEYPAD MASTER 15X7 CAPS graphic.bas      | 40X1   | 2079B  | 545 low 0                  | 401F    | Command does no effect, continues to next line
                                                           | 548 pause 700              | 403A    | Stayes on this line 'forever'
 
KEYPAD MASTER 15X7 CAPS GRAPHIC cfd1.bas | 40X1   | 2063B  | 546 if typrel=1 then       | 3FFD    | [PC=2406]; [PC=241B]; Run then pause: [PC=2426] 'forever'
 
KEYPAD MASTER 15X7 CAPS GRAPHIC CFD2.bas | 40X1   | 2079B  | 545 low 0                  | 401F    | Command does no effect, continues to next line
                                                           | 547 if typrel=1 then       | 4030    | Command improperly executed by jumping to the line underneath rather than "else" when typrel =0
                                                           | 548 pause 50               | 403A    | Terminates: Internal Exception: divide by zero in module 'AXEVSM1.DLL'. (No "let varl=varl/0" etc. in program)
 
KEYPAD MASTER 15X7 CAPS GRAPHIC CFD3.bas | 40X1   | 2063B  | 546 if typrel=1 then       | 3FFD    | [PC=1C05]; [PC=6272], Invisible "high 0"; [PC=6280]; +$E every step - 50th time=[PC=653C] continues: polled in4, executed "keyled" ("keyled" command not in program), -to [PC=8C79] 'forever'
 
Graphic lcd for atahdd.bas               | 40X1   | 3991B  | 790 b0=b0-32               | 4002    | Instead of "b0=b0-32", it does "high 0" instead, Continues to next line
                                                           | 791 gosub audatab0 '###... | 4010    | Simulation terminates - Internal Exception: access violation in module AXEVSM1.DLL'.
 
GRAPHIC LCD FOR ATAHDD cfs1.bas          | 40X1   |        | 783 next b4                | 3FE7    | Rather than jump under "for b4=0 to 20" on line 778, 3F02, it goes [PC=43F1]; [PC=4403]; [PC=4414]; b0=33; [PC=4451]; [PC=4462]; terminates with "access violation in 'AXEVSM1.DLL'"  
 
GRAPHIC LCD FOR ATAHDD CFS2.bas          | 40X1   |        | Completely skips this: 778 3FAE if hdb0=hexbin0 then
                                                                                    779 3FF8      w0=ch6line6
                                                                                    780 4010 else
                                                                                    781 4018      w0=ch6line7
                                                                                    782 ---- endif
                                                           | 784 b1=autowrite           | 4045    | Command does no effect. Continues to next line
                                                           | 785 gosub comb1            | 4062    | Program continues to next line without completing this sub-procedure
                                                           | 786 for b4=0 to 20         | 407A    | Completes sub-procedure "comb1", b4=21, continues to next line
                                                           | <Line simulation continues to be off-sync until back under "main".>

symbols & key:
In keypad master 15x7 caps graphic {cfd$}.bas:
symbol typrel=bit3


In graphic lcd for atahdd {cfs$].bas:
symbol hdb0=bit16
symbol hexbin0=1
symbol ch6line6=105
symbol ch6line7=126
symbol autowrite=%10110000
<sub 'audatab0' (including the one that is jumped to: 'dskip' starting on $331B) is between addresses $3189 and $339E>
<sub 'comb1' is between addresses $3611 and $36C9>


every ; means 'then after (another) click on the step button' unless otherwise stated.

on each [pc=####], the code window is blanked, and displays "no source code in pc address [pc=####]."


This concludes that the havoc caused by the chasing fault starts on the commands in the program bit addresses $4000 onwards.
For example, the havoc (incorrect line simulation) starts on b0=b0-32 in bit address $4002, onwards in the program
'Graphic lcd for atahdd.bas'.
This means at the moment, I cannot simulate an X1's program in vsm, that occupies program bit addresses beyond $4000,
without the posibility of getting erratic line simulation on bit address $4000 onwards. Similary, I cannot simulate an X1's
program in vsm that is longer than 2048 bytes, half of 4096.

Remember that it is not any of the command's fault. If any of the commands (including their end commands e.g. 'endif' if
it was 'if ...')
mentioned in the data are put in bit addresses before $4000 rather than in $4000 onwards, they execute correctly.

Does this help you better than posting one full program in posts #34 and #37, to fix this program-space-limiting chasing fault?

 

[tiscando]

More to the big picture

More to above:

I think that who created axevsm1.dll from axevsm.dll might have forgot to change the maximum allowed program bytes for the x1 parts from 2048 bytes to 4096 bytes elsewhere apart from the initial syntax checker, or the addressing on the program parts beyond $4000 is out of sync with the addressing before $4000.

This is why that I think you can see that all the program memory bit addresses that are mentioned in the table are near $4000, which is where the problem lies.


Also, I have downloaded post #19,#20 attachments and added more fault-tracing info onto post #19 (especially program addresses). When I first created these posts, I wasn't sure about the basic nature of the fault that was repetitively hindering me. Please refer to this post for another example of this. I don't think it is a fault with the select_case after all; that program is yet another victim of the beyond-$4000 axevsm1 fault which limits X1 programs below 2048 bytes, half of 4096.


Moreover, same problems described on a different (new) PC.

 

[tiscando]

Command at address investigation.

While waiting, I have been recently doing more axevsm1 fault tracing.
Here, I've created a table of commands and their incorrect effect at
certain program bit addresses (on next post).

Info about the tester program:

The 'axevsm fault tracer#' program is based from the 'keypad master
graphic' program, and had the input poll and serin commands replaced
with 'let var' commands. Next, I created comments on where the resizer
commands (that are there, but are skipped by a goto command) goes, and
where the tested command goes.

The resizer code ended up being a number of 'pause 10' commands, and
there are 9 rows of 5 : stacked 'pause 10' commands, and an extra 4
after, already in the attachment code. The purpose of this is to bring the
tested command up to near address $4000.

Moreover, I've created a circuit with just a 40x1 with it's download
circuit and a terminal connected. This is so I can watch the pin states
and see any activity on the TxD pin when I am investigating (debuging).

I placed a breakpoint on a 'low 1' command near line 530 in the VSM
debug window.

This is how I operate it:

- I add more 'pause 10' commands into the resizer code, and state the
number of them in the table;
- I add a command onto the test area, and start a row on the table
stating the command, and the address it appears at, on the left fields;
- I clicked the RUN button
- When the debug windows pop up, I clicked on the step in button to
step through the program until a command does something incorrect
(usually at an address near $4000 of course!), and I start entering
this and the commands after into the table after the listing of the
test command.
- If the code window blanks out and displays "no source line at PC
address [PC=$$$$]" where $ is a hex digit, I start stacking these onto
the table in the 'what happens...' field, and what also happens, after
each click on the 'step in' button. Please note the key at the bottom
of the table.
- When I add something onto the schematic, e.g. a terminal, then I state that a terminal is added, in [], before the command row.

What I've done so far is in the next post; the table exceeds the maximum post text size, so I had to include it in a .txt attachment


key for the table:

- every ; means "then after a(nother) click on the 'step-into source line' button in the code window, "
 
- every , means "and what (also) happens there, " OR "Next, "
 
- "err log msg" stands for "error log message appears and says"
 
- "IE:AVIM'AV1.DLL'" stands for "Internal exception: access violation in module 'axevsm1.dll'"

I hope this is more evidence of the fault in the simulator part of axevsm1.dll that limits X1-part programs down to 2048 bytes (half of 4096 which is the real maximum for an X1 chip) because when a command is placed so they occupy a program memory address at $4000 and above inside the X1, it executes incorrectly (does something not intended) and/or seizes/misdirects program flow. This is the basics of this fault I've been talking about throughout half of this thread, but didn't realize until post 44.

 

[tiscando]

Command at address table

OK, Here's the 'command at address table' in the attachment.

Good luck!

 

[Dippy]

Blimey, you seem to be having more issues than everyone else added up.
The posts are very long and well beyond me, but who is all this aimed at based on Technical's last reply?

 

[tiscando]

Blimey, you seem to be having more issues than everyone else added up.

Yep, probably because I create and test a lot of circuits with the program, and found and investigated components that I didn't know about before, e.g. the graphical LCDs; and that I bother to report problems as soon as I know that the problem is really strange (as in not referenced in manuals or datasheets), and I've tried everything I know to try and fix it.

I've also structured the above post clearer, and highlighted the basics of the fault at the bottom.

but who is all this aimed at based on Technical's last reply?

- I think this is aimed at who created the AXEVSM*.DLLs etc.
- After that, I was trying to give different ways of reporting the fault, and also found out the basics and patterns of the fault.

Sorry for the persistence, but I'll list the conclusion again (looking at the table): When a command (or any part of it) in an X1's program lies on the program memory addresses $4000 and beyond, and the program comes to this command, it: improperly executes, does something not intended, misleads it's dependant commands, misleads target PC addresses for the next command (When the code window displays "No source line at PC address [PC=####]) and/or seizes program flow (either stays on the command or PC address 'forever', or terminates with a red error message in the error log). What happens (and what happens with the commands after this command in the program that occupy address $4000 and onwards) depends on the type of command, it's parameters, and which program memory address it's situated on. If the program does move onto the next command (on an address further up), then any of the above symptoms are repeated on that command.

All this, is the fault I'm talking about, and definitely hoping it will be fixed for the next release (with the new X2 parts).

 

[tiscando]

hserin background receive and h-I2C slave mode

I would like to know why it's hard to implement the hser background receive and h-I2C slave mode features onto picaxe VSM.

Is this feature going to be applied for the next release (with the X2 parts)???