| View previous topic :: View next topic |
| Author |
Message |
bcs99
Joined: 22 Nov 2003
Posts: 32
|
| Code changed by itself? |
 Posted: Mon Apr 19, 2004 2:34 pm |
 |
|
I'm having a wierd problem with an 18F452. It seems to have changed it's code to run the wrong sub-routine at startup. How is it possible for the code to have changed like that without the chip in a programming state? The unit is in the field so I will have to wait a few days to get at it to check it out.
Any suggestions/tips would be very appreciated.
Bob |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
|
bcs99
Joined: 22 Nov 2003
Posts: 32
|
|
| Posted: Mon Apr 19, 2004 11:59 pm |
|
|
Thanks.
I'm using 3.182.
I'll look a little closer at the bug.
Bob |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Tue Apr 20, 2004 12:29 am |
|
|
CCS fixed that bug way before vs. 3.182, so I don't
think that's the problem.
If the code that's running appears to be different from
the code that you just compiled, I would make sure that
your programmer is really pointed at the correct directory
when you load the .HEX file. Check the date and time
of the .HEX file before you load it into your programmer.
Put a printf statement at the start of your program that
displays the current version.
Also look here:
http://www.ccsinfo.com/versions.shtml
See if your problem could be caused by any of the things
they fixed in the versions that came right after 3.182.
Other things to check:
1. Watchdog timer running at a shorter time period
than expected, due to chip variation or temperature.
2. Forgetting to put NOLVP in the #fuses statement.
3. Using a programmer that ignores the #fuses statement
and uses its own settings, which you overlooked.
4. Running a chip at low voltage, when it's not specified for it.
5. Running a chip at an oscillator frequency that is not
recommended for the oscillator #fuse setting that you're using.
6. Leaving the MCLR pin floating, or doing something weird with
the MCLR circuit (ie., a circuit other than a simple pull-up to VDD). |
|
|
bcs99
Joined: 22 Nov 2003
Posts: 32
|
| Problem solved |
| Posted: Tue Apr 20, 2004 11:20 am |
|
|
This was a little bit of forsight and a little bit of personal memory loss on my part. Too many late nights, I guess.
There was a problem in that the external eeprom memory got damaged/erased and the initial setup was lost. This data is only supposed to be calculated once, the first time it is used, so I never thought about it being the source of the problem. The forsight was that the program was again looking to do the setup which it was supposed to do when the eeprom settings were not present. Many of the tips you suggested have already been done and the unit had been working in the field for some time now. So I knew the code was working correctly.
I guess my next question would be why did the eeprom get erased? I'm using a 2402 with the supplied device driver "2402.c" and have had no problems until now.
Bob |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
