Firmware does not execute

I would agree to start with the stack. Count the number of nested calls (where one function calls another) Do the same for the interrupts (And again for each priority level used) Then add them up. That Plus the memory uses should be greater than 256.

Note is you are using a chip with less than 256 RAM use that.
Insure you are using the correct memory model.
Are you using Banking?

I would agree to start with the stack. Count the number of nested calls (where one function calls another) Do the same for the interrupts (And again for each priority level used) Then add them up. That Plus the memory uses should be greater than 256.

Note is you are using a chip with less than 256 RAM use that.
Insure you are using the correct memory model.
Are you using Banking?

Thanks for the replies. I will try all recommendations and come back to this topic.

A few things that I can reply on:

-The stimulator did not give me much pleasure.
-When I debug the firmware real time, it jumps to an interrupt and get stuck there (I need to verify this again).
- When I say it stops working, I mean, It does not execute as it is supposed to (It jumps to locations where it is not supposed to).
-When I check for errors I do check for corrupt pointers and bad interrupts but did not have a look at the stack.
-I have 4k of RAM and use a large memory model.
-No, I don't bank.

"When I say it stops working, I mean, It does not execute as it is supposed to (It jumps to locations where it is not supposed to)."

Never abreviate when you ask for help with a problem. Give the symptoms as clearly as you can instead of just saying that it fails.

Stack overflow will often result in the application jumping to strange locations. Without room on the stack, the application will fail when returning from a function call or an interrupt service routine. It is quite easy to catch a stack overflow in the normal call sequence, but stack overflows for an interrupt is very problematic, since the interrupts happens asynchronously.

I still haven't had a chance to look at the problem again but can I increase the stack size? (In the startup code?)

Is it I good idea to increase the stack size (if possible) or should I reduce the nested calls. Not that I think I branch to much.

Yes sorry for not providing all the necessary info. I was tired and fed up.

What about the linker/locater, could it be possible that the wrong memory size and/or location is defined?

What about the linker/locater, could it be possible that the wrong memory size and/or location is defined?

I doubt it, unless you are getting a warning during linking.

What you can do upon startup is to fill your stack with a known pattern, like 0x55 interleaved with 0xAA, and check the stack space with the debugger / code. if the pattern is gone, so is your program...

Yes sorry for not providing all the necessary info. I was tired and fed up.

Aren't we all. Can you imagine somebody here making a hit on you here (see 'Miss Embededd'. the typos are in the source, not mine! I give her the need to vibrate, or something).

"I give her the need to vibrate..."

Yes, at a 50% duty cycle.

Timers at the ready!

-The stimulator did not give me much pleasure

-I give her the need to vibrate

Erik

looks like I've come to the wrong sort of forum :-o

How do I view the stack memory (RAM) in the Keil IDE. I can only find a view of the code memory?

It will be in IDATA

http://www.keil.com/support/man/docs/uv3/uv3_cm_display.htm

I had a look at the assembly.

The startup code has a LJMP to C_START (In this case C_START is at address 0x112E). But the firmware at this address is a function that is called at a later stage during execution. So the C_START address is incorrect. But just after that assembly line is another LJMP to the correct address (main() at address 0x17E5) which is not executed.

Before the firmware execute the LJMP to 0x112E I change the PC to 0x17E5 and the program will the execute as it should.

Why will C_START have the wrong address?

You never mentioned the name of the function that the first LJMP jumped to.

Do you have any functions with leading underscores?

Maybe you have a function with the same name as an initialization function in the runtime library. The startup code may try to call an init function in the runtime library to set up the required variables for printf(), ... and now manages to call one of your functions instead.

Hello Mister Poindexter,

Does the executer get to main?

The startup code has a LJMP to C_START (In this case C_START is at address 0x112E). But the firmware at this address is a function that is called at a later stage during execution. </iSo the C_START address is incorrect. But just after that assembly line is another LJMP to the correct address (main() at address 0x17E5) which is not executed

There is, and should not be, any 'functions' called from startup.a51. compare whatever you have to the 'standard' startup.a51.

startup.a51 should ONLY be mdified to do whatever absolutely needs to be done immediately after reset is gone (in your case that would be a watchdog disable)

Erik

"startup.a51 should ONLY be mdified to do whatever absolutely needs to be done..."

Unless ... you have sufficient knowledge of the mechanics and are confident in your ability to predict the operation.

In the right situations, modification or replacement of the startup code can be very useful.

I would like an example of something that does not "absolutely need to be done immediately after reset is gone" where it will be advantageous to locate it in startup.a51.
Sure, with the ultimate care, you can run your entire program from Satartup.a51 but I just can not imagine anything beyond what I posted where it will be advantageous to do so.

Erik