Forum - MCS Electronics

 

FAQFAQ SearchSearch RegisterRegister Log inLog in

Do STCHECK,$HWCHECK,$FRAMECHECK,$SOFTCHECK work

 
Post new topic   Reply to topic    www.mcselec.com Forum Index -> BASCOM-AVR
View previous topic :: View next topic  
Author Message
njepsen

Bascom Member



Joined: 13 Aug 2007
Posts: 412

newzealand.gif
PostPosted: Sun Aug 23, 2020 12:39 am    Post subject: Do STCHECK,$HWCHECK,$FRAMECHECK,$SOFTCHECK work Reply with quote

I am chasing an issue where a global gets changed when it should not, and i have been chasing this for 2 days now.
The last time anyone posted on the various 4 tools (shown above) for checking stack was 8 years ago, and at that time it seemed to me that consistent results were not being seen between STcheck and the other 3 at that time.
I don't want to go down that rabbit hole right now.
I have run STCHECK in several places and only ever got 0 as a result. Ive set the stack to the maximum space allowed but I still have one particular long variable that gets corrupted. Because the code is 8000 lines long its not practical to post the relevant code other than to say that the long is only set at one place in the entire code, and is corrupted somewhere else when it should not be.


Code:


$regfile = "m1284pdef.dat"                                
$crystal = 9830400                                        
$framesize = 1200                                          
$hwstack = 1200                                              '
$swstack = 1200
$frameprotect = 1
config submode = old                                        
$include "config_mmcsd_hc.bas"                          
$include "config_AVR-DOS.BAS"
$PROG &HFF , &HC7 , &HD0 , &HFD


(BASCOM-AVR version : 2082 , Latest : 2.0.8.3 )

_________________
Neil
Back to top
View user's profile
JC

Bascom Member



Joined: 15 Dec 2007
Posts: 489
Location: Cleveland, OH

usa.gif
PostPosted: Sun Aug 23, 2020 2:08 am    Post subject: Reply with quote

Very frustrating, I'm sure.

While it could be a stack issue overwriting the stack, other problems could cause this, also.

For a test, try disabling interrupts when you create or process that variable, then re-enable them.
It is always possible that the variable is getting trashed by an ISR.

Is the variable used within an ISR?
If so, recall that not all registers are saved, etc., when calling an ISR.
That can cause some odd bugs that are difficult to track down.

I don't know how the compiler orders the variables in memory.
But, for kicks, one could try to make the compiler place the variable causing a problem in a different location in memory.
Then, perhaps, that variable would survive correctly, and a different variable would be corrupted / over-written.
That would help to verify that the variable was being over-written by an adjacent variable / array in the stack line up.
You could Dim the variable as the first one in the list, perhaps, or DIM / add another variable of the same type.
Then do something with that variable so that it isn't optimized out of the memory.

Are all of your arrays 0 based or 1 based, and are you absolutely sure you are not trying to write to an indexed array location that isn't Dim'd, i.e. that does not exist?
That, also, can be a difficult bug to find.

Finally, can you, at least for now, replace some (lengthy) subroutines with canned data and REM the actual code.
This is to significantly shorten the program, (although it won't work quite right...).
The goal is to see if you can use some canned data, and make the program still run, and see if the variable now survives.
Then add back in the modified routines one at a time.
This both lengthens the program, and perhaps points to the subroutine that causes the problem.

Does the program run correctly on an older version of the compiler, or has it never run correctly?

Have a spare LED on the board?
Depending upon the overall structure of your program you might be able to check the specific variable's value at multiple points within your program, (i.e. at ten locations spread through your Main Loop), and at the entry or exit of some key ISRs.
The goal is to see if there is a particular place within the code that always trashes the variable, and does so reproducibly.
That helps to track down the specific routine or line of code that causes the problem.

If the variable gets trashed at totally random / different times every time the program is executed then it is harder to identify, as it might well be dependent upon specific ISR's firing and specific data processing...

JC
Back to top
View user's profile Visit poster's website
MWS

Bascom Member



Joined: 22 Aug 2009
Posts: 1827

blank.gif
PostPosted: Sun Aug 23, 2020 9:53 am    Post subject: Reply with quote

JC wrote:
I don't know how the compiler orders the variables in memory.
In the order as declared.
njepsen wrote:
but I still have one particular long variable that gets corrupted.
A long variable or a long-variable?
I would check the preceding dim'd vars, especially strings and other array types.
If it's an range overflow error, stackcheck isn't suitable.
Back to top
View user's profile
Evert :-)

Bascom Expert



Joined: 18 Feb 2005
Posts: 2114

netherlands.gif
PostPosted: Sun Aug 23, 2020 1:35 pm    Post subject: Reply with quote

JC wrote:


I don't know how the compiler orders the variables in memory.

You can see that in the report. (Press the "show result" button)

_________________
www.evertdekker.com Bascom code vault
Back to top
View user's profile Visit poster's website
njepsen

Bascom Member



Joined: 13 Aug 2007
Posts: 412

newzealand.gif
PostPosted: Mon Aug 24, 2020 1:57 am    Post subject: Reply with quote

Thanks Fellas for coming back to me on this, and thanks for your efforts especially JC.
I HAVE FOUND THE PROBLEM

It was your comment mws that variables are stored in the order in which they are declared which was the clincher, and the other clue was that the variable ( which is a long) was not trashed, but always only had its last 4 digits changed.
The problem was in my declarations, the previous variable was a string which was 3 bytes too short, and from time to time ( several minutes), it overflowed into my long.
DUH !!

Simple problem, hard to find, silly mistake.

Thanks guys.

_________________
Neil
Back to top
View user's profile
AdrianJ

Bascom Expert



Joined: 16 Jan 2006
Posts: 2472
Location: Queensland

australia.gif
PostPosted: Mon Aug 24, 2020 2:07 am    Post subject: Reply with quote

Great you solved it !

One thing I used to do to trace this sort of corruption was to rearrange the order variables are defined. Then see whether the corruption happens on the same or a different variable. If its still the same variable, its most likely an ISR or stack problem. If its a different variable, its more likely a DIM overflow error, as you found.

Its probably good practice to put all the strings after all numeric variables in the DIM list, they are the ones most likely to cause this sort of problem.

_________________
Adrian Jansen
Computer language is a framework for creativity
Back to top
View user's profile Visit poster's website
njepsen

Bascom Member



Joined: 13 Aug 2007
Posts: 412

newzealand.gif
PostPosted: Mon Aug 24, 2020 3:00 am    Post subject: Reply with quote

Hi Adrian,
yes you are probably right. All my var are in alphabetical order so i can easily find them.
Once bitten, twice shy.

_________________
Neil
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    www.mcselec.com Forum Index -> BASCOM-AVR All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum