I have almost finished writing my program but I noticed some problems with it. I am currently using an Atmega168 mcu. The problem I am experiencing is that some variables seem to get overwritten by others or the program simply hangs. At other times the timer interrupt simply doesn't fire, etc.This leads me to believe that I might have used too much memory. At a quick glance, I have this:
1 array(8) = 9 b
15 byte vars = 15 b
7 word vars = 14 b
1 long var = 4 b
1 integer var = 4 b
~ 30 bytes used inside the LCD, Wait, Tone functions
The chip has 1024 bytes of RAM and I am using at most 100 bytes of them. In the generated ASM file, the first var starts at
.EQU CHR=256
up to the last one at
.EQU USEDEGF=443
The difference between the addresses is 187 bytes (this includes all my vars, arrays and GCBasic's internal stuff). Where is the rest of the RAM? Is there anything I can do to be able to use the memory to its full?
Thank you.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Top of mega168 ram should be 0x04FF or dec 1279. You have tried to fill the SRAM to this point, and GCB is preventing this? I have not experienced a problem with using large arrays with the Mega168 previously.
As far as debugging the code to find the problem, it needs to be broken down to its most basic elements of functionality and assessed from there. Blink the led, make the tone, institute an interrupt, communicate over a serial protocol, etc.
If these one of the basic functions doesn't work properly, then the structure of the code, variable assignments, typo's etc. can be looked at more closely. On variable assignments use distinct names not easily confused with the internal reserved variables like x,y,z etc.
So to help you, a little more work on your part, and post back with discrepancies observed, and code that can be compiled and looked at by those interested in helping.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi. I don't get any errors from the compiler itself, it's just that the code shows signs of memory corruption. I will try my best to split it up and find the problem. First I will change variable names in order to avoid overwriting internal stuff as you suggested.
Thanks for the answer.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The compiler version is 0.94 (from the current GCB@Syn package). I don't really think the compiler is to blame here though. Most probably I screwed something up since I've seen very complex programs made with GCB and no one complained so far :-).
Currently I am rebuilding the program piece-by-piece while manually keeping track of the variables and subs. I'll keep you posted.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Got some good news. After placing a prefix for all the vars and subs, the memory corruption has stopped. I probably was overwriting something. To test things I even declared an extra 512 byte array without any trouble at all.
Regarding the timer problem I was having, on the InitTimer0 page in the manual, it is falsely written for AVR that the following primary constants are accepted:
PS_1, PS_8, PS_16, PS_32, PS_1024
The timer.h file is correct in having only these defined (checked against the datasheet):
PS_1, PS_8, PS_64, PS_256, PS_1024
Unforunately I was calling "InitTimer0 Osc, PS_16" and the compiler probably thought PS_16 was a byte with value 0. I think it would be nice to have an explicit mode where all variables must be defined manually.
The second issue I found while trying to find out why the interrupt wasn't firing is that in eeprom.h in the PIC section the interrupts are turned off while writing / reading but for AVR the interrupts are left active. Shouldn't AVRs have this protection as well?
Thanks for the help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Glad you got the variables sorted, it sounded like that type of behavior from your description. And, it appears you have stumbled on a couple of items to add to the GCB tick list. Hopefully it will be smooth sailing from here on out.
It would appear that a simple workaround for disabling the interrupt would be?
cli 'disable global interrupts
<EPWrite code>
sei 'enable global interrupts
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I have almost finished writing my program but I noticed some problems with it. I am currently using an Atmega168 mcu. The problem I am experiencing is that some variables seem to get overwritten by others or the program simply hangs. At other times the timer interrupt simply doesn't fire, etc.This leads me to believe that I might have used too much memory. At a quick glance, I have this:
The chip has 1024 bytes of RAM and I am using at most 100 bytes of them. In the generated ASM file, the first var starts at
.EQU CHR=256
up to the last one at
.EQU USEDEGF=443
The difference between the addresses is 187 bytes (this includes all my vars, arrays and GCBasic's internal stuff). Where is the rest of the RAM? Is there anything I can do to be able to use the memory to its full?
Thank you.
Top of mega168 ram should be 0x04FF or dec 1279. You have tried to fill the SRAM to this point, and GCB is preventing this? I have not experienced a problem with using large arrays with the Mega168 previously.
As far as debugging the code to find the problem, it needs to be broken down to its most basic elements of functionality and assessed from there. Blink the led, make the tone, institute an interrupt, communicate over a serial protocol, etc.
If these one of the basic functions doesn't work properly, then the structure of the code, variable assignments, typo's etc. can be looked at more closely. On variable assignments use distinct names not easily confused with the internal reserved variables like x,y,z etc.
So to help you, a little more work on your part, and post back with discrepancies observed, and code that can be compiled and looked at by those interested in helping.
Hi. I don't get any errors from the compiler itself, it's just that the code shows signs of memory corruption. I will try my best to split it up and find the problem. First I will change variable names in order to avoid overwriting internal stuff as you suggested.
Thanks for the answer.
What version of GCB? We did fix a memory issue in the recent release.
And, I think Kent recommendation is a great way forward.
The compiler version is 0.94 (from the current GCB@Syn package). I don't really think the compiler is to blame here though. Most probably I screwed something up since I've seen very complex programs made with GCB and no one complained so far :-).
Currently I am rebuilding the program piece-by-piece while manually keeping track of the variables and subs. I'll keep you posted.
Got some good news. After placing a prefix for all the vars and subs, the memory corruption has stopped. I probably was overwriting something. To test things I even declared an extra 512 byte array without any trouble at all.
Regarding the timer problem I was having, on the InitTimer0 page in the manual, it is falsely written for AVR that the following primary constants are accepted:
PS_1, PS_8, PS_16, PS_32, PS_1024
The timer.h file is correct in having only these defined (checked against the datasheet):
PS_1, PS_8, PS_64, PS_256, PS_1024
Unforunately I was calling "InitTimer0 Osc, PS_16" and the compiler probably thought PS_16 was a byte with value 0. I think it would be nice to have an explicit mode where all variables must be defined manually.
The second issue I found while trying to find out why the interrupt wasn't firing is that in eeprom.h in the PIC section the interrupts are turned off while writing / reading but for AVR the interrupts are left active. Shouldn't AVRs have this protection as well?
Thanks for the help.
Glad you got the variables sorted, it sounded like that type of behavior from your description. And, it appears you have stumbled on a couple of items to add to the GCB tick list. Hopefully it will be smooth sailing from here on out.
It would appear that a simple workaround for disabling the interrupt would be?