Code behaves diferent in studio and when running standalone

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

Hi

In an xmega project with display xplained, debugged using jtagice2, we have encountered a strange problem when using avrstudio. I remember that I have read about similar problems before where code behave different when device is debugged using studio and when it is running freely with no debugger connected, but I could not find the specific threads right now.

Case is that when code is debugged from studio, it behaves as expected, and its task is to write text to the display at given position.

But when we close down studio and disconnects jtag, re powering the device, the screen gets blanked every time text is to be written, then after a while text is written to display at correct position but everything else is gone.

First i thought that studio might have added breakpoints to code so we reprogammed the device, but with same result.

What i need is some input to start debugging and find the source of this behaviour. We thought it was related to uninitialized variables somehow, but this has been checked out. What could be the diference between running code using the debugger compared to run a fresh programmed device.

Thanks in advance

Regards
Vidar (Z)

----------------------------------------------------------

"The fool wonders, the wise man asks"

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

How does it behave if you run it from AVRstudio with the JTAG connected, but just run the program without any breakpoints or interruptions? Anytime something changes the AVR execution timing (like the debugger) it can mask real time execution problems and allow broken program code to successfully execute, but only with the JTAG debug modified execution timing (like stopping on a break point, single stepping, etc.).

Is anything else (like your own external hardware) connected to the JTAG pins?
http://www.atmel.com/dyn/resourc...
4.2 JTAG interface
4.2.1 Shared use of JTAG lines

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

Its the same, I have tried that, with no breakpoints set ever.
As long as the code is run from studio, with or without breakpoints, single stepping etc. etc. It will work as expected, but try running the same code standalone, it will "break" even if programming via avrdude and never having studio connected. Run code from studio again and voila.

I am using the Atmel Display Xplained board and there should not be anything else connected to the jtag lines, except they are routed through a b2b connector to the display board.

Regards
Vidar (Z)

----------------------------------------------------------

"The fool wonders, the wise man asks"

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

Missing/bad ground connection between controller board and display board by any chance?

Stefan Ernst

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

Nope, and it should have been giving random behaviour.

However, I just found the source for my problem and its as usual a bug in the sw, what could it be, but the tricky part, for me, then became to understand why it then behaved differently for studio and in standalone.

Case is. I have a gui where I can specify a number of icons to be drawn. This is done using a pointertable that gets allocated dynamically where size is given by the number of icons to create. Each icon has a structure defining its size, placemnet etc.

You then fill the allocated structure members and the display update routine will detect that a number of icons is to be drawn. Case is that I removed initialising of a certain icon, but I did not update number of icons to allocate space for and which where to be drawn, thus I now had an icon pointing to non initialised memory. The display update function thus filled the entire screen with nonsense.

Thing is that Studio, I guess, will initialise memory space to all 0x00 by some reason (why on earth would we want studio to do that, its not real life), and thus the non initialised icon has a size of 0 making no troubles. Running standalone however, the memory cant be predicted, and problem arise.

Please fill inn if you have info of why Studio behaves like it does.

Regards
Vidar (Z)

----------------------------------------------------------

"The fool wonders, the wise man asks"

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

Quote:
Please fill inn if you have info of why Studio behaves like it does.

I didn't notice AS4 does such things while starting debugging session. I am almost sure it does not! What is your build?

You say that when you start a debugging session, all SRAM locations and registers are 0x00, even when the previous session was terminated with a mess there?

Strange, anyway, it seems there is a solution. Generate several random memory space views and preload memories at startup of the session. There is an option in JTAG MK1 setting (so I guess in Mk2 also) to skip flashing the device at the start of debugging section - do it manually.

No RSTDISBL, no fun!