nubie 89c4051 conundrum

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 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

Reply to
Rob
Loading thread data ...

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.

Reply to
Gary Kato

...

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

Thad

Reply to
Thad Smith

snipped-for-privacy@aol.com (Gary Kato) wrote in news: snipped-for-privacy@mb-m16.aol.com:

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

Reply to
Rob

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.

Reply to
Gary Kato

Thad Smith wrote in news: snipped-for-privacy@acm.org:

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

Reply to
Rob

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

formatting link
(916) 780-7623

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

Reply to
Albert Lee Mitchell

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.

Reply to
Gary Kato

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
Reply to
Tim Mitchell

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.