We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Dear All,
I am using Silabs 8051F340 micro controller and USB debug adapter to download the code to my target CPU.
The problem i am facing is my code works fine when i reset the system using my debug adapter by keeping adapter connected to target CPU. But once i remove the debug adapter from system and switch on system on independent power supply; it shows erratic behavior and doesn't work properly.
Note: My system doesn't have RESET switch. But i feel power on RESET is okay..
Kindly suggest me.
Thank you, Ameya
Why do you feel your target reset is working?
Have you looked at the reset pin with a scope while in the power up mode?
How are you providing a reset signal on your target board? Bradford
i had a problem where my code worked fine if there was a breakpoint. When let run free it would work fine and recieve a command from the uart once then crash when i send a second command. Turned out to be with breakpoints set it caused enough of a delay to skip a byte comming into the uart. Never noticed it because that byte would be disgarded in processing anyway. It took one extra line of code to fix after 2 days of hair pulling. When let run free the extra byte caused the program to crash...
So it could be a similar timing issue. But you dont describe the eratic behaveior. Also if you dont have an rc reset circuit or a reset chip, i'd add one.
No, this does not sound like a sw error. This very much sounds like an incorrectly driven reset line.
but the SILabs derivatives (f0x-f2x) require a resistor (I use 2k2) from the reset pin to Vcc to have a reliable power on reset.
Erik
"SILabs derivatives (f0x-f2x) require a resistor (I use 2k2) from the reset pin to Vcc to have a reliable power on reset"
Do you consider that a sufficiently reliable reset, or would you still recommend an external reset-generator (or "supervisor") chip?
I'm just asking - I don't know!
"Code only works with Debug adapter"
With these key words, I remember these causes and solutions.
a) Noise to the reset (C2CK) and/or C2D pins - pull up both pins. b) Slowly-rising power supply - solved by an external supervisor chip to the reset pin. c) Broken GND connection - just the debug adapter gives GND connection to PC
Tsuneo
I have 1000s of single processor boards where this works without a glitch.
My 'theory' about built-in resets is that chips with a lot of analog have good built-in resets whereas for chips where the reset is the only analog feature it is usually lousy.