| View previous topic :: View next topic |
| Author |
Message |
picj1984
Joined: 01 Mar 2010
Posts: 73
|
| Strange code behavior with unused global variables? |
 Posted: Wed Sep 04, 2019 10:39 am |
 |
|
Hello all. I'm using compiler v4.140. I just had kind of a crazy thing happened. I was having some weird issues with the behavior of my code and I found that only deleting / commenting out unused global variables completely solved my issue. Even when compiling I got warnings from the compiler saying that these variables were unused (before removing them).
Has anyone every experienced these issues? For now, I'm just going to be much more vigilant about commenting out or deleting unused variables, but was hoping I could get some more info from more experienced people. |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Wed Sep 04, 2019 1:15 pm |
|
|
Unused globals still take up space in memory.
Look at the .SYM file in "before and after" compilations for clues. |
|
|
allenhuffman
Joined: 17 Jun 2019
Posts: 537
Location: Des Moines, Iowa, USA
|
|
| Posted: Wed Sep 04, 2019 1:52 pm |
|
|
I've had issues where moving a comment up or down a line would prevent the debugger from working, so I've certainly seen odd things 
Was it an int8 by any chance? We had an issue where another int8 was sharing the same 16-bit value, and we had enough globals/statics that the variables ended up past the 0x1fff boundry in memory. That made the compiler generate multiple-steps to access these 8-bit values (load 16-bit, modify, store). We had an ISR that was using one of the sides of the word (and int8) and it could corrupt the other side if they were being accessed when the IRQ came in. That shouldn't apply with non 8-bit values, I don't think.
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ? |
|
|
picj1984
Joined: 01 Mar 2010
Posts: 73
|
|
| Posted: Wed Sep 04, 2019 2:11 pm |
|
|
| allenhuffman wrote: | I've had issues where moving a comment up or down a line would prevent the debugger from working, so I've certainly seen odd things
Was it an int8 by any chance? We had an issue where another int8 was sharing the same 16-bit value, and we had enough globals/statics that the variables ended up past the 0x1fff boundry in memory. That made the compiler generate multiple-steps to access these 8-bit values (load 16-bit, modify, store). We had an ISR that was using one of the sides of the word (and int8) and it could corrupt the other side if they were being accessed when the IRQ came in. That shouldn't apply with non 8-bit values, I don't think. |
Interesting..... it was 4 arrays that had 4 values each in them. All declared as 'unsigned long int'
I wasn't using them so just deleted them on a whim and everything is happy. I added them back in just to be sure. made absolutely sure it was just them. and same weird behavior from before. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9097
Location: Greensville,Ontario
|
|
| Posted: Wed Sep 04, 2019 2:18 pm |
|
|
| which PIC ? how much RAM is used ? |
|
|
picj1984
Joined: 01 Mar 2010
Posts: 73
|
|
| Posted: Wed Sep 04, 2019 2:32 pm |
|
|
| temtronic wrote: | | which PIC ? how much RAM is used ? |
PIC16F1527
RAM: 35 - 39%
ROM: 53% |
|
|
allenhuffman
Joined: 17 Jun 2019
Posts: 537
Location: Des Moines, Iowa, USA
|
|
| Posted: Wed Sep 04, 2019 2:39 pm |
|
|
| picj1984 wrote: |
Interesting..... it was 4 arrays that had 4 values each in them. All declared as 'unsigned long int'
I wasn't using them so just deleted them on a whim and everything is happy. I added them back in just to be sure. made absolutely sure it was just them. and same weird behavior from before. |
If you are using the CCS IDE, you can enable generating the Symbol table file. It will show you where in memory the variables (static and global, anyway) will reside. In the IDE on the "View" tab are links to view the "C/ASM List", "Call Tree" and "Symbols". Check out Symbols and see.
Look for stuff that looks like this:
| Code: |
. . . snip . . .
800-1FFF memory
2000 value1
2001 value2
2002-200A realTimeClock
200B value3
200C value4
200D function.s_value1
200E-2010 threeBytes
2011 function.s_value2
2012 MAIN.s_value7
2013 MAIN.s_value8
4780-47FF Stack
4780-4781 _STACK_
ROM Allocation:
000200 timer3_isr
. . . snip . . . |
Starting at 0x800 are the values. Adding those globals in may be moving things down.
at least on some PICs (we use PIC24s), after 0x1fff the assembly used to access variables changes. It could be that it's pushing other variables past that location and changing the code generation and there's some unexpected interaction going on.
I'd be curious to see where your globals live when they are in.
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ? |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19215
|
|
| Posted: Thu Sep 05, 2019 12:21 am |
|
|
Some comments:
Are these possibly static globals?. If so, I remember an issue existing
around that time, with these not always behaving as expected. Also
remember that a static variable will always be cleared to zero, so the
presence of a variable does change things.
Again obvious question about 'what chip'?. Remember that on a PIC16 for
example, the memory is 'paged', so the presence of a variable could be
forcing other parts of the code to do bank switches. I see you have now
posted the chip, so 'yes' this could apply. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
