Atmel Studio + XMEGA and global variable corruption

Go To Last Post
6 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a fairly large Atmel ASF (v7.0) project with composite USB and ADC that is used in a custom board with ATXmega16A4U (sensor). Everything has been working well for months, until I ran into a bizarre for me issue with a global variable. Particularly if I declare it with an initialization to non-zero, the program misbehaves randomly, and unrelated variables are flipping values "by themselves", or the MCU would even reset (I guess it does a bad jump based on some other variables).

 

S16 temp = 53;

 

There is no issue if I replace 53 with 0.

 

The issue reproduces even if the only use of this variable is temp++;

 

I have been trying to simplify the code to provide a trivial repro but it makes the problem go away.

 

It might be somehow related to USB, because if I don't call udc_start(); there is no problem. As soon as I start USB, even if I don't send any USB commands, the issue begins. (unrelated variables randomly changing values as verified by outputting them to the board LEDs)

 

I compared HEX files with and without the assignment, and things look as expected, numerous bytes have incremented by +2, the rest is the same.

 

I'd appreciate any pointers on how to debug this.

 

                Program Memory Usage     :    10190 bytes   49.8 % Full
                Data Memory Usage         :    1042 bytes   50.9 % Full

 

 

This topic has a solution.
Last Edited: Fri. Nov 13, 2020 - 07:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Look for stack issues. The simulator might be worth a try.

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In situations like this I always look in the .MAP file, or whatever GCC calls it (I use Codevision), to see where the variable is and what's around it.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> The simulator might be worth a try.

 

Can the simulator talk USB to the host PC?

 

> I always look in the .MAP file

 

Yes, GCC has that too, fascinating, first time I look at it. Comparing the 2 map files looks good - the variable switches between the bss and the data segments. Interestingly, the variable in question is right after a huge USB table, along with other USB stuff:

 

.bss.udd_sram  0x00802398       0x54

 

I am wondering whether the USB code is accessing something out of bounds. And this brought the memory that I wasn't quite sure what to set these defines to, so I kind of guessed them. I guess I guessed wrong :)

 

#define  USB_DEVICE_EP_CTRL_SIZE       64
#define  USB_DEVICE_NB_INTERFACE       3
#define  USB_DEVICE_MAX_EP             3

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

And absolutely, going through the USB defines, I had a mistake - MAX_EP should be 4. With that fixed, both versions of the code above work fine!

 

Thanks so much. A new tool in my toolbox :-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

purple_beam wrote:

A new tool in my toolbox :-)

 

I have found so many bugs just by a visual inspection of the MAP file. It's so easy to spot what is likely to corrupt a variable, especially when you spot that it sits just after a buffer.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."