Memory locations being incorrectly written to?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Memory locations being incorrectly written to?

2,326 Views
r_howell
Contributor I

I am reluctant to think this problem is with my processor, so I'm posting here under the assumption that it is perhaps a setting I am uninformed of when it comes to my dev environment / debugger.

I am writing an embedded application for a MC9S08QE32 product used on a wireless radio product within CodeWarrior dev studio for MCU, v 10.2). When I compile my code and go into debug mode with my MultiLink Universal device, I am getting some strange behavior during the very basic initialization portion of my main() function.

As you can see in the attached picture, when I step through the initialization line for line, everything is OK until I get to:

prev_prs_avg=0; 

 ... which is a u16. At this point, as you can see on the Variable tab on the right, it updates the value in prv_prs_avg to 0, but also updates drop_count in the process, presumably because the u16 is spanning or overlapping this memory location. Does anyone know what causes this to occur, or why the system would assign a variable to a memory location that was already allocated? It also appears to be modifying 0x0725 and 0x0724, but shouldn't it be attempting to change 0x0725 and 0x0726 (U16 = 2B)?

Thanks,

 

Labels (1)
3 Replies

2,247 Views
r_howell
Contributor I

Thanks for willing to help. I ended up reading about compiler optimization and this seems to be secondary to some of the events that get skipped over, perhaps if the compiler considers the process redundant. I ended up trying it with optimizations disabled and it seemed to thoroughly set every variable location in memory. 

0 Kudos
Reply

2,247 Views
ZhangJennie
NXP TechSupport
NXP TechSupport

Good to know it. Thanks for the sharing.

Have a nice day,

Jun Zhang

0 Kudos
Reply

2,247 Views
ZhangJennie
NXP TechSupport
NXP TechSupport

HI Richard

Please upload your demo project. Thus we can reproduce it and look into it directly.

Thanks,

Jun Zhang