I'm using the Silicon Laboratories C8051F345 with the Keil IDE.
I now have two different projects of which the firmware won't execute. If I comment random pieces of code the firmware will execute. I am still within the memory limits of the device.
From my point of view, the compiler is not configured correctly for the device or I assign my variables incorrectly. I ran out of ideas, tired of searching and pulled almost all my hair out of my head.
I program alone and don't have anyone to look at my source.
I want to ask if someone experienced will please have a look at my project to point any possible mistakes or problems.
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?
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...
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)
"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.
"I would like an example of something that does not 'absolutely need to be done immediately after reset is gone'..."
I think it'd be better if any examples and/or further discussion of this particular point were taken to a separate thread...
Sorry, but I don't have the time follow this on for too long but will say this:
I have occasionally had to support code with unusual memory maps and awkward battery backed non-volatile rollback data recovery.
Sometimes these could be placed outside startup.a51 and sometimes, due to timing constraints, to do so would have caused a window for potential data loss.
The word advantageous could simply refer to better code layout/structure/modularity.
My point really was that a well seasoned developer should not be afraid of writing or modifying any mixed C/ASM code - So long as that developer has sufficient understanding of the whole environment.
And that includes the startup code.
Whoops - Just seen Andy's response after I posted a response.
I will refrain from continuing the discussion here.