nubie 89c4051 conundrum

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hi to all.
Bit of a nubie hoping for some advice / help.
I am having a problem with a mico application that I have developed /
written.
I am using an 89c4051from Atmel , and am writing the software in C.
The compiler that I am using is Raisonance.
The problem that I have is that the software keeps jumping out of the
main DO...While(1) loop , and I can't figure out why. The software seems
to run fine
most of the time , but now and then jumps out of the infinite loop.
I'll try to explain the code layout.

/*
definitions etc
 #define <reg51.h>
etc
etc

variable definitions

prototypes

//-----------------------------------------Main function / program              
              
void main(void)

{
    P1_2 = !P1_2;   // inserted later to try and find problem
    initialise();    // initialise function , sets up comms , timers etc

         do
            {

             do stuff and call various functions



           }
         while(1);

}
//----------------------------------------------------------


various functions

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

Hope this gives some idea of the program structure.
The P1_2 = !P1_2 I inserted later to try and find where things were going
wrong.
I monitor this pin with the scope and every time it changes I know that
point in the
software has been reached , or that instruction has been run.
There are no other references to P1_2 or port 1 as a whole anywhere else
in the software.(Yet :0))

On startup that instruction ( P1_2 = !P1_2;   ) is run before going into
the do_while loop , but that point in the code should never be
run gain , barring a reset or power cycle. Correct?
As I mentioned I am new to this , so I may be wrong.
Anyway , that instruction does keep happening every now and then. How is
this possible.
Unless 1 does not equil 1 :0)
The compiled code generates 2400 odd bytes of code and 91 bytes of RAM.
The 4051 has 128 bytes of ram.

A few thaughts I had.
1. Stack overflow----- could this cause this sort of problem , and how
can I check if this is happening.
2.Uninitialised pointer(s)----- not using any.
3.Watchdog chip ( Dallas 1232)  causing resets---- does not seem to be
the case.

Any thaughts on this would be much appreciated.I am a bit stumped here. I
have tried another chip , to no avail.
Cheers
Rob

 



Re: nubie 89c4051 conundrum
Sounds like the CPU is getting reset. If it's not the watchdog chip, then it
might be the built-in brown-out detection. At what voltage are you running the
CPU? Brown-out gets triggered at 2.1V +/- 10%.

How much stack space do you have allocated? You can probably do an estimate of
how much stack you are using. Look at the instructions that the compiler issues
for such things as allocation of local variables, passing arguments to
functions, as well as the function call itself. The 8051 is a Harvard
architeture, so I'm not sure if the hardware stack is only used for subroutine
nesting or if it's used for data as well.

But a stack overflow doesn't necessarily mean you'll get a reset. You might
just start running somewhere unexpected in code. Just the sort of thing your
watchdog timer chip is meant to catch.


Re: nubie 89c4051 conundrum
snipped-for-privacy@aol.com (Gary Kato) wrote in

Quoted text here. Click to load it

Chip is running at 5v. Definately not brownout.
I have not "allocated" any stack space , this must be all done by
compliler.How would I manually allocate stack space?
I am not passing many arguments in my functions , but there are a few
nested functions.Does this use up a lot of stack space?
There is 37 bytes os ram available. Seems quite a lot to me.
Cheers
Rob

Re: nubie 89c4051 conundrum
Quoted text here. Click to load it

I didn't see that you had mentioned how much RAM your code was using in your
original post. As for how much stack space is being taken up, you have to look
at the machine code that your compiler is generating for those function calls.
It's possible that  the arguments are being passed in some of those allocated
RAM bytes already and won't go on the stack. 37 bytes of stack seem more than
adequate if you don't nest very far. You may want to count how many levels you
do nest. You might also look into any C library routines you use.

As for allocating stack space, it depends on the toolset you use. Usually
there's a way to specify such things with the linker. Don't know whether x51C
tools are that fancy (I've only used Forth and assembler).

One way to check for stack overflow is to fill the stack with a fixed value
using your debugger, then start your program. When it resets, look at the stack
RAM and if you don't see any bytes with that fixed value, you know they got
overwritten.


Re: nubie 89c4051 conundrum

Quoted text here. Click to load it
...

My guess is stack overflow, especially if interrupts are being
serviced.  You might have to put the program on a RAM diet.

Thad

Re: nubie 89c4051 conundrum

Quoted text here. Click to load it

Hi there. Tried the same software on an 89c52 , 256 bytes of ram
same problem.Don't think it is a ram /stack problem.
Tried rearanging some of the code. Improved things , only seems to jump
out of the do...while(1) once just after startup and some of the code is
run. After that it does not seem to do it again.
Baffled
Rob

Re: nubie 89c4051 conundrum

Quoted text here. Click to load it

Rob:
    The problem you're encountering is pretty common developing most any
project.  None of us know every weirdness or can predict every behavior.

    What this does demonstrate, in my opinion, is one limitation of a purely
compiled language, the difficulty in debugging.  Most people either
persevere and eventually twiddle the code enough to find one combination
that works or use an emulator or an In Circuit Emulator to manually step
through their code.

    Your problem is also an arguement for an interpreted language such as
Basic or Forth.  Basic is slow but at least you can manually execute
portions of your code to deduce most problems.  Forth is both fast and
interpretative, some say "incrementally compiled."

    It's not my intention to start yet another language war but do consider
alternatives to this "compile then puzzle" development cycle.  If your
code doesn't work, how do you test?

 
-- Regards, Albert
----------------------------------------------------------------------
AM Research, Inc.                  The Embedded Systems Experts
http://www.amresearch.com (916) 780-7623
----------------------------------------------------------------------


Re: nubie 89c4051 conundrum
Quoted text here. Click to load it
Is it possible to see how the compiler has coded the program? (i.e. the
assembly language code it has generated) This might offer some clues.
--
Tim Mitchell

Re: nubie 89c4051 conundrum
Quoted text here. Click to load it

Almost sounds like an unintialized variable. Somewhere along the line, it gets
initialized properly  and your code starts behaving.

Another thing that can cause execution weirdness is not using function
prototypes. If a function declaration differs from the function definition, all
kinds of stack screwiness can happen. I took over a project where the previous
engineers hadn't used prototypes (and had turned compiler warnings off) and
crashed every few minutes.


Site Timeline