Stone dead .....? From kicking and sparking

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

Hi, Im back; its never too late to give up...

 

A atmega 8 code fairly large (2,5k hex-load) has been running smooth, from C code; however I made a major inclusion of new routines

 

now the machine seem not even to start; i.e. I light a led in main() more or less directly as a test output using a led that works fine

on the same pin when reverting to the version before; which makes me wonder;

 

what can cause a atmega8 not to start or go out into  the woods before even getting into code main; as said there is no fancy in the

newly included code only  some routines  in  C which as most advanced set i/o pins.

 

I dont include code here since I find it too large, and dont know where in it  to start looking. Guess there must be some compile/link issue ?

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

Did you run out of flash or SRAM?

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

wouldnt that be detected by the tools (gcc or avrdude) ?  I see that avrdude loads some 3.3k flash (but I guess there should  be 8 :)

on the other hand I had expected that there would be more code increase from the previous version (which loads on some 2.8k)

could there be a truncation somewhere ?

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

If you use most of your SRAM, you can get strange results as the stack or other dynamic SRAM usage wanders into the statically assigned memory.

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

OK! so all variiables go onto the SRAM, and that is a total of 512 ? and then stackframes (what else?) for calls go onto that, so the deeper nesting........

is that what could be on the menue ?

Last Edited: Wed. Sep 13, 2017 - 09:46 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Calls, interrupts, any other pushes.  How much free SRAM do your tools say you have?  That has to be enough for the greatest dynamic SRAM requirements, which can get hard to determine.  It would help if you could catch the point of failure in a debugger.

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

As kk6gm says, it's hard to determine toeal RAM usage - including "dynamic" usage during run time (call stack with return addresses and local variables, dynamic allocation..). But you could probably tell us what "static" RAM usage you have. E.g. Atmel Studio reports this at the end of the build process. E.g. if you're close to 100% already for the statics then RAM/stack overflow is a good bet.

 

With experience, a rough estimate of maximum dynamic RAM usage can be done. Each active call costs the return address (2 bytes(?)) and then all parameters and local variables in the function. An int is 2 bytes, a long is 4 bytes etc. Figure out (this is the "with experience" bit what would be the largest "call chain" and do a rough add-up. Interrupts are a bit tricky since they can, by definition, happen anytime. OTOH, unless you're doing advanced stuff you have at most one ISR active at any given time, and they don't have parameters and probably few and small local variables. So you add your "worst ISR" to the worst case for your "normal functions" (if the ISR i n turn calls other functions it get a little more "hairy"..)

 

gechxx wrote:
I dont include code here since I find it too large, and dont know where in it  to start looking.

You've already stated that it won't even lit a LED at the start of the program. The question is if you let it continue running after that? If so, then anything after the lighting of the LED could nullify that quicker than you can see. E.g. repeated bogus resets/restarts. Let your main() start with lighting the LED and the immediately after that have

while (1);

i.e. hang in an eternal loop there.

 

Is the LED on?

No: Something goes wrong very early and we might have more questions to ask, and things for you to test.

Yes: Move the eternal loop construct forward (i.e. to later points) in your program, in small steps. Observe where the program stops keeping the LED lit, and you're onto it!

 

And do double-check that you LED-lighting code is correct. Did you set the applicable DDRx bit? Not on a pin that has alternate function active, e.g. JTAG? (Theres nothing worse than having a bug in the code you add to debug the application... ;-)

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"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

kk6gm wrote:
It would help if you could catch the point of failure in a debugger.
mega8A doesn't have a debugger whereas a mega88 does (debugWIRE)

Do mega88 have data breakpoints?

If yes then can set a data breakpoint to detect a stack overflow.

 

Atmel Studio

General Information on Data Breakpoint

http://www.atmel.com/webdoc/GUID-ECD8A826-B1DA-44FC-BE0B-5A53418A47BD/index.html?GUID-CC67F575-4C06-4BD1-B5BF-44ED2142C215

Atmel Studio

Stack Overflow Detection Using Data Breakpoint

http://www.atmel.com/webdoc/GUID-ECD8A826-B1DA-44FC-BE0B-5A53418A47BD/index.html?GUID-A4FC8DB5-6B28-4893-93BA-7A4406698E5D

 

"Dare to be naïve." - Buckminster Fuller

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

Hi ! thanks for good advice:

 

SO I hope you didnt read this until now; of cause I should tripple check the LED workings; now with while() and a change of 1 - 0 setting for LED pin its on (ashamed)

     so now Ill have to go on and see what else might be there

 

- inserted the while(1);   ( instead of the _delay_ms(2000) which  I had at that position directly after the LED on... ;

 

  ( actually I found a fun thing by accident; I have a number of routines  in a library, but I have a compilation linkage script that doesnt include that library, by misstake

   i started that script and found that i ACTUALLY linked and produced the .hex, while I had expected it to violently complain over missing refererences to routines !

   so the linker/compiler is so smart that when the  while(1) IS inserted, it realizes that all those routines will never be called, so there is no use of linking them in !!! 

   further more, this  is also seen in the size of the resulting load .hex file, it is substancially smaller)

 

- and YES im regrettful  that I didnt use the atmega88 for the project, but the chances of de-soldering and substituting and getting the electic to work are not too high.

 

- I have counted the number of word equiv (16bit) variables I use in the C code and come to a figure of somewhere 40, while the SRAM for m8 is 500 words, so,

  I guess that the amount should not really be a problem ?

 

- yes I have double checked the LED, but should possibly tripple check,  DDR seem ok, the bit mode for light up seem ok (set to 1 ) (as in original code that works when reverting)

  dedicated I/o pin (PB0)

 DARN: I have now tripple checked by testing setting bit other direction ; and see there IS LIGHT

 

- Im not very much into the studo (on the learning curve, have been working directly with gcc-avr so far, and emacs editor), but yes, I have built it with the A-studio  (v7.0) as

 well, and didt get complaints (mmore than a series of warnings for unused vars, ..... to be developed)

 

Ill be back after more investigations Now I at least have response from main()

Last Edited: Thu. Sep 14, 2017 - 12:08 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There seem to be something really strange going on. .....

 

I cannot do anything but refer this to; sorry to take your time, and the swedish SBS (freely trnslated as Shit Behind the Steeringwheel), I have recompiled code and libraries, and

redone the scrpits for comp&link, (and keep the initial code lightning of LED, for superstision only) and now it works. A day gone. Thanks for support.

Last Edited: Thu. Sep 14, 2017 - 04:31 PM