Difference between debugging and programming

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

Hi all,

I am experiencing a strange problem:
In short, If I am programming my target board - it does not run. However, if I hit the debug button and the debugger programs the target board, I can press the run button and the target runs without any problems. I can then leave the debugger - cycle power on the target, and it still runs without any problems.

The detail.
I am using tools and the environment as stated below.

AVR Studio:Version 4.14 build 589
GCC from WinAVR-20080512
Target CPU is on custom board - Atmega644P
When programming or debugging;
JTAGICE II in JTAG mode via USB
On programming panel of the JTAG
Main tab:
Device is set to ATmega644P and signature verifies correctly.
Programming mode is set to JTAG.
On the Program Tab:
I use the .hex file generated by the compiler for programming. Programming and verify runs correctly with no errors.
On Fuses tab:
BODlevel is set to 111
JTAGEN is tacked
SPIEN is ticked
bootfalsh size is set to 512 - not used
SUT_CKSEL is set to ext crystal osc 8.00 meg and startup 16K+65ms
LockBits tab:
no locks are set
Hardware info tab says:
Hardware Revision: 0x01
Firmware Version: 0525 0525

I have attached a zip file with screen captures of my project options. I have added no include directories and have not changed the memory settings.

Anybody with any ideas or suggestions.
Regards

Attachment(s): 

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

OK start a debug session (which succeeds) then on the Debug menu use "upload/download memory" to read the code image back out of the chip and then compare hex files against the one you are trying to program

(apart from 0xFF padding they should be the same - if they aren't it may give you a clue)

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

Hi there, Good advice!

I programmed using the debugger, then exited and ran the device programming - there I did a verify. Verify found an error which said:
Flash byte address 0x0002 is 0x96 (should be 0xD6).. Failed

I don't quite know what lives here - will investigate.
Still - how come the difference in programming. This is probably a difference between the generated .hex and .elf files.

Thanks

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

First off, EXCELLENT information provided by the OP regarding the issue!! We don't get much of that most of the time.

Second,
My guess is that you might have a bed(defectife) AVR. A simple test would be to write a small program that toggles an LED, and try running that on the target. If the problem goes bye bye then the micro is probably alright. If not then I'd say the AVR should be retired.

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

Hi there,
Sorry I am only getting back to this now, I've been on an all day product demo yesterday, and therefore, have not had any time to investigate this issue further.

To the preceding poster, I think you've missed the point. My embedded application completely works with all features if I use the debugger to program the app into the Mega644P. Of course, this uses the .elf file for programming. The same app if programmed using the programming panel - using the .hex file to program - does not run.

What makes this problem a little bit complicated is that may app is >300K of C code in lots of separate modules, and it is going to take some time to pull it apart to try and localise the problem. So I will be back in a couple of days - hopefully with more info. In the mean time, if anybody has further suggestions on how to approach this - your most welcome to make suggestions.

I think it is important to get to the bottom of this, as on face value, this looks like either a bug in the compiler toolchain - gcc. Or a bug in the programming sections of AVRstudio. To try and eliminate, I will start by trying to use another programming software with the same .hex file to see if the bug goes away. This will localise the bug in either gcc or AVRstudio. - I think.

Regards
Johan

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

Quote:

The same app if programmed using the programming panel - using the .hex file to program - does not run.

Sorry if the following is "below your level". I do not want to offend you (but am speaking from own experiences):

Have you made absolutely sure that you are referring to the correct HEX file? If you do a search over the complete hard drive for files with the specified name and delete them, then re-build, then program with that hex-file, is the problem still there?

Regards
Johan

8)

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

Hi Johan,
After 20 years in development I have learned a long time ago that there is no such thing as 'below my level', and that there is nobody else on this earth that can stuff me around better or more than I can myself.

As it turns out again, you were right - I have been missing the obvious. Thanks for your comment - it put me on the right track. Working 14 hour days for the last two weeks and jumping between projects have made Jack a dull boy.

So, to the rest of you - please ignore me - I feel stupid.

Johan :lol: