RAM issue on specific variable v3.5.0.6 vs v4.0.4.8

[trastikata]

The symptom is that ram byte at location 0x73 (sometimes based on program size it moves up or down in location) is changing when no assignment is made to them, when compiled in v4. The change happens when other activities in program execute and other unrelated ram bytes are changed. When compiled in v3.5 with zero program changes no such issue occurs. 

Unless the variable associated with RAM location 0x73 is fixed to that location with the directive At, then this changes nothing and as we said - this is normal and it is not a symptom of anything. So again, this is not the issue causing your program to behave differently.

[Dompie]

Do I understand correctly (without source I find it very difficult to follow) that the bootloader has been loaded and that another program has been loaded and executed and this other program (not the bootloader) changes addresses 73 and 74?

Johan

[kcsl]

Maybe I'm not understanding the initial issue, but it sounds like you believe a variable is changing it's value unexpectedly. You believe that something, possibly another variable, is overwriting all or part of the first variable, meaning that the two variables are affectively overlapping each other, trying to share the same memory addresses and so interfering with each other ?

[PicNoob]

Maybe I'm not understanding the initial issue, but it sounds like you believe a variable is changing it's value unexpectedly. You believe that something, possibly another variable, is overwriting all or part of the first variable, meaning that the two variables are affectively overlapping each other, trying to share the same memory addresses and so interfering with each other ?

That is my thought yes. When compiled in v4 the variable changes despite all references to changing it being commented out.

[PicNoob]

The symptom is that ram byte at location 0x73 (sometimes based on program size it moves up or down in location) is changing when no assignment is made to them, when compiled in v4. The change happens when other activities in program execute and other unrelated ram bytes are changed. When compiled in v3.5 with zero program changes no such issue occurs. 

Unless the variable associated with RAM location 0x73 is fixed to that location with the directive At, then this changes nothing and as we said - this is normal and it is not a symptom of anything. So again, this is not the issue causing your program to behave differently.

Maybe I am understanding the assembly incorrectly then. I thought that the compiler assigns memory locations at compile time resulting in fixed locations in the assembly file.

So in the assembly file I have this in the definitions. I cut it short but the variable with the issue is calc_torque, which is a word, so we have calc_torque and calc_torqueH.

I'm not sure what the difference between "standard variables" and "start of bank0" is referring to but as I mentioned assembly is not really my world. I presume standard variables are some area of ram before bank0? Space set aside for system that is unused? In any event are you saying that although calc_torque starts at 0x77 in bank0 here, that it will move around within the program? If so that makes finding the problem much more difficult.

; STANDARD VARIABLES
tmap_in equ 0x3E
tmap_inH equ 0x3F
fp_in equ 0x40
fp_inH equ 0x41
map_in equ 0x42
map_inH equ 0x43
tmap_out equ 0x44
tmap_outH equ 0x45
fp_out equ 0x46
fp_outH equ 0x47
map_out equ 0x48
map_outH equ 0x49
rpm equ 0x4A
rpmH equ 0x4B
tempW equ 0x4C
tempWH equ 0x4D
tempW2 equ 0x4E
tempW2H equ 0x4F
tempW3 equ 0x50
tempW3H equ 0x51
index equ 0x52
index_usb equ 0x53
output_count equ 0x54
output_countH equ 0x55
boost_zero equ 0x56
boost_zeroH equ 0x57
n1MINRPM equ 0x58
n1MINRPMH equ 0x59
n1MAXRPM equ 0x5A
n1MAXRPMH equ 0x5B
dutycycle equ 0x5C
dutycycleH equ 0x5D
CANprescale equ 0x5E
CANprescaleH equ 0x5F
; START OF RAM BANK 0
CANprescale2 equ 0x60
CANprescale2H equ 0x61
USBOUT4 equ 0x62
USBOUT4H equ 0x63
shiftRED equ 0x64
shiftREDH equ 0x65
shiftRED2 equ 0x66
shiftRED2H equ 0x67
meth_in equ 0x68
meth_inH equ 0x69
boost_zero_ECU equ 0x6A
boost_zero_ECUH equ 0x6B
boost_pivot equ 0x6C
boost_pivotH equ 0x6D
boost_pivot_map equ 0x6E
boost_pivot_mapH equ 0x6F
USBOUT8 equ 0x70
USBOUT8H equ 0x71
e85_analog_in equ 0x72
e85_analog_inH equ 0x73
throttlePOS equ 0x74
oilTEMP equ 0x75
oilTEMPH equ 0x76
calc_torque equ 0x77
calc_torqueH equ 0x78
waterTEMP equ 0x79
waterTEMPH equ 0x7A
timing equ 0x7B
timingH equ 0x7C
boost_zero_map equ 0x7D
boost_zero_mapH equ 0x7E
ewg_in equ 0x7F
ewg_inH equ 0x80
ewg_out equ 0x81
ewg_outH equ 0x82
data_checksum equ 0x83
rpm_last equ 0x84
rpm_lastH equ 0x85
methAVG equ 0x86
methAVGH equ 0x87
fpAVG equ 0x88
fpAVGH equ 0x89
misc_in equ 0x8A
misc_inH equ 0x8B
exp1 equ 0x8C
exp1H equ 0x8D
EGTtimer equ 0x8E
EGTtimerH equ 0x8F
storage_address equ 0x90
storage_addressH equ 0x91
storage_addressHH equ 0x92
storage_addressHHH equ 0x93
sent_in equ 0x94
sent_inH equ 0x95
sent_in_temp equ 0x96
sent_in_tempH equ 0x97
sent_in_error equ 0x98
sent_out equ 0x99
sent_outH equ 0x9A
sent_out_temp equ 0x9B
sent_out_tempH equ 0x9C
maf_in equ 0x9D
maf_inH equ 0x9E
maf_out equ 0x9F
maf_outH equ 0xA0
solenoid_out equ 0xA1

[trastikata]

Maybe I am understanding the assembly incorrectly then. I thought that the compiler assigns memory locations at compile time resulting in fixed locations in the assembly file.

I am afraid you are getting completely confused by the insufficient knowledge (please don't get offended) of the Assembler listing.

A variable or variable name is just an alias for given memory location, for example "MyVariable" means memory location 0x35 - that location is being assigned at compile time and for most of the common operations it doesn't matter what memory location is being assigned. The compiler knows that values being read from or to "MyVariable" means actually reading and writing from or to memory location 0x35.   

Anyway if you don't want to share any program code I think you should focus your effort on describing what actually is happening. For example:

- You have variable called "MyVariable"
- You assign value to that variable at compile time, for example "Dim MyVariable as Byte = 55"
- You do nothing with "MyVariable" but when you try to display it (serial port or some display) it appears to have different value than per-assigned i.e. in case of this example, the value is different from 55

Did I understand the problem correctly?

[PicNoob]

Maybe I am understanding the assembly incorrectly then. I thought that the compiler assigns memory locations at compile time resulting in fixed locations in the assembly file.

I am afraid you are getting completely confused by the insufficient knowledge (please don't get offended) of the Assembler listing.

A variable or variable name is just an alias for given memory location, for example "MyVariable" means memory location 0x35 - that location is being assigned at compile time and for most of the common operations it doesn't matter what memory location is being assigned. The compiler knows that values being read from or to "MyVariable" means actually reading and writing from or to memory location 0x35.   

Anyway if you don't want to share any program code I think you should focus your effort on describing what actually is happening. For example:

- You have variable called "MyVariable"
- You assign value to that variable at compile time, for example "Dim MyVariable as Byte = 55"
- You do nothing with "MyVariable" but when you try to display it (serial port or some display) it appears to have different value than per-assigned i.e. in case of this example, the value is different from 55

Did I understand the problem correctly?

Yes that is correct. When compiled in v4 I can see the variable changing values in my serial interface, when there is no explanation or path for those values to change. The same program compiled in v3.5 does not have this bug. I don't mind sharing some code but I don't believe it will move the ball forward as its a large complicated program and I have been unable to recreate the issue in a small program.

My theory for the issue is that the v4 compiler is doubling up or not properly managing a RAM address for the specific variable, which is why I dove into the assembly file in the first place.

So my theory is that for example if calc_torqueH is mapped to ram 0x78 at compile time, somewhere in assembly I should find some other reference writing or overflowing into ram address 0x78. 
 

 

[PicNoob]

Do I understand correctly (without source I find it very difficult to follow) that the bootloader has been loaded and that another program has been loaded and executed and this other program (not the bootloader) changes addresses 73 and 74?

Johan

Unfortunately we went off on some tangents here. But the basic issue is that a specific ram address (it moves around within a small range based on program size) is getting corrupted when compiled in v4 but not when compiled in v3.5, and I'm trying to find some way to identify the cause in the assembly file to run it up the flagpole for a repair. Or find some other explanation for the cause like an array or stack overwrite or something, which I haven't been able to find, and which should be the same in either compiler.

[trastikata]

Yes that is correct. When compiled in v4 I can see the variable changing values in my serial interface, when there is no explanation or path for those values to change. The same program compiled in v3.5 does not have this bug. I don't mind sharing some code...

For the moment please forget about Assembler, I repeat, from what you are writing here, it looks like due to lack of sufficient knowledge of the Assembler, you are getting more confused by trying to give sense to things. 

Please upload the entire program file and indicate which variable is changing values with no obvious reason.

[PicNoob]

Yes that is correct. When compiled in v4 I can see the variable changing values in my serial interface, when there is no explanation or path for those values to change. The same program compiled in v3.5 does not have this bug. I don't mind sharing some code...

For the moment please forget about Assembler, I repeat, from what you are writing here, it looks like due to lack of sufficient knowledge of the Assembler, you are getting more confused by trying to give sense to things. 

Please upload the entire program file and indicate which variable is changing values with no obvious reason.

I can't post it but let me know your email and I can email it over!

[PicNoob]

I found another interesting item that might be related. The code when compiled on v4 executes around 15% slower than when compiled on v3.5. So maybe whatever is causing this variable issue is also slowing it down.

The main reason I prefer to use v4 is the compile time is much faster and the code is usually more compact. Compile time of like 15 seconds vs 90 seconds. But I didn't consider the execution speed might also differ.

*** EDIT *** mysteriously, now I can't recreate the ram issue, even compiling an unmodified version that had had the issue yesterday. I didn't take an ASM backup of when it had the issue so can't compare to see if there are any differences but I don't see how there could be. So strange and annoying. Only change from yesterday to today was restarting the PC and working on other unrelated programs. But I just redid the speed test and the code compiled in v3.5 still executes 15% faster than the code compiled in 4.0.5.4 for whatever reason.