View previous topic :: View next topic |
Author |
Message |
jecottrell
Joined: 16 Jan 2005 Posts: 559 Location: Tucson, AZ
|
Port F & G Quit Working |
Posted: Sat Apr 14, 2007 11:48 am |
|
|
18F6627 @ 40MHz & 5V
3.236 and 3.249
OK. I admit that some of this is my fault, but when you try to debug code and the compiler isn't producing a fair representation of what you sent it.... that gets a little frustrating.
In my original code a started using fast_io on port f & g (I should have put two and two together...) After days of having everything work correctly, all of a sudden F & G quit altogether. I go back to basic code and try to toggle pins on F & G.... no luck. I replace the processor ($15!). No luck.....
I start scratching my head.... compiler problems?
I restart my PC and compile w/ 3.249 and it works! I restart again and revert to 3.236 and it works!
Any explanation?
Thanks,
John |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Sat Apr 14, 2007 11:54 am |
|
|
Have you been installing different versions of PCM and PCH, changing
them once a day or so ?
This can cause a problem because the DEVICES.DAT file in one version
might not be compatible with another version.
See Darren's post in this thread:
http://www.ccsinfo.com/forum/viewtopic.php?t=19614 |
|
|
jecottrell
Joined: 16 Jan 2005 Posts: 559 Location: Tucson, AZ
|
|
Posted: Sat Apr 14, 2007 12:08 pm |
|
|
Quote: | Have you been installing different versions of PCM and PCH, changing
them once a day or so ? |
No. I should clarify my OP. #.249 is on a laptop and 3.236 is on a desktop. I installed that way to prevent questions about just such issues.
Correct sequence of events was:
Problems with 3.236 on desktop.
Moved code to laptop and compiled with 3.249. (worked)
Restarted desktop and recompiled w/ 3.236. (worked)
So, really the only corrective action was to restart the computer....
Thanks,
John |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Sat Apr 14, 2007 12:30 pm |
|
|
If you're switching source files between computers, the most common
reason for quirky behavior is that the source file(s) that you think
you're compiling are not really the files that you're compiling. You
might have copied them into the wrong project directory, or you picked
up the wrong floppy of your desk, or the project points to a different
directory than the one you think it points to.
All the same arguments apply to the resulting HEX files.
Also, it might be possible that MPLAB is setup for a slightly different PIC
(in the same family), but the Device ID's aren't sufficiently different for
MPLAB to determine this.
Look for something like this to be the cause. And of course the usual
things like accidentally having XINST turned on, and the lack of bypass
caps on the power pins. |
|
|
|