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.
What happens if you strip your project of everything but the startup file and main containing nothing but an infinite loop?
Then it works. I've done that several times. Removing all sources except for the main with its initialization. Then added piece by piece, file by file. As I come to a certain point (no specific file) it will stop working. Then I will check for any errors in that file, but none.
I really don't know what is going on. So I need an expert to have a look at what I'm doing.
Hello Master Poltergeist,
Does the code work in the IDE stimulator?
What kind of errors are you looking for?
There will not be any syntax errors -because the compiler would have found them.
So you need to look for things that will only manifest at runtime - eg, stack overflow, corrupt pointers, bad interrupts.
The SiLabs parts have on-chip debug hardware, don't they? Are you making use of it?
If this is a commercial project, look here:
http://www.keil.com/condb/
SiLabs may well have a similar list...
hello?
i need samsung LTS500W1-PD1 datasheet.
please upload imedetly.
thank you.
it will stop working.
What does that actually mean, i.e. how do you know it's no longer working? What's it supposed to do, and what does it do instead?
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?
"upload imedetly."
Sorry you had to wait. It's uploaded now.
king kang = king kong ?
sir henry
where did you put my file? i can not find it!
did you attach to the message?
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?
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).