 |
 |
| View previous topic :: View next topic |
| Author |
Message |
picj1984
Joined: 01 Mar 2010
Posts: 73
|
| Same .c file, different buggy .hex file 1 week later |
 Posted: Tue Jul 03, 2012 4:26 pm |
 |
|
Hi guys,
I'm at a loss. I've searched the forum and can't find anything similar to my problem.
Here's my information:
Compiler Version: 4.121
| Code: |
#include <16f1936.h>
#fuses HS, NOWDT, NOLVP,
#device ICD=TRUE
#device ADC=10
#use delay(clock=16000000, int)
|
On Thursday, June 21st I compiled some source code and put the .hex file on 6 prototypes. They all worked great. Today we got about 500 production units. I was going to fix one extremely small bug, but I loaded the old code on the production units. All sorts of crazy stuff started happening.
So, I think something is wrong with the production units... but there's not. I read the old .hex file from one of the prototypes and put it on the production units and everything was perfect again.
Next, I grabbed the old .c file from 6/21/12 to see if I inadvertently changed anything but they it is IDENTICAL to the one I'm compiling today. Unfortunately I did not back up the .lst files so I can't check to see if that is identical to the one being produced today.
Long story short, a .c file compiled on 6/21/12 works perfectly.... and the same .c file compiled today has massive, massive bugs... but you can still see some semblance of the program working.
Does anyone know what could be going on??? |
|
 |
temtronic
Joined: 01 Jul 2010
Posts: 9226
Location: Greensville,Ontario
|
|
| Posted: Tue Jul 03, 2012 4:49 pm |
|
|
Providing YOU haven't done anything with the compiler or source code since then...
my knee jerk reaction is 'what software on the PC was 'upgraded',either by you or in the background that you don't know about?'
A test that 'might' work, is to do a 'system restore' to that 'good' day and see what happens.
I'd also do an external backup ,say to flashdrive, of the good-dot-c file ASAP.
Heck, you could have your C drive going 'funny', a Windows glitch,an 'autoupdate' that didn't install right,....1,000s of possiblities, but my crystal ball is fuzzy today.
For the past few years, my 'power off screen/harddrive' options get 'reset' all by themselves and I've yet to find the culprit to that gremlin...
hopefully you will find the cause and a solution soon !
hth
jay |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Tue Jul 03, 2012 5:04 pm |
|
|
I made your code snippet into a little test program and compiled it with vs. 4.121:
| Code: |
#include <16F1936.h>
#fuses HS, NOWDT, NOLVP,
#device ICD=TRUE
#device ADC=10
#use delay(clock=16000000, int)
//===========================
void main()
{
while(1);
}
|
Here is what it says at the bottom of the list file:
| Quote: |
Configuration Fuses:
Word 1: 19E4 INTRC_IO NOWDT NOPUT MCLR NOPROTECT NOCPD NOBROWNOUT NOCLKOUT IESO NOFCMEN
Word 2: 0EFF NOWRT NOVCAP PLL_SW STVREN BORV19 DEBUG NOLVP
Some fuses have been forced to be compatible with the ICD debugger.
|
Comments:
1. You have specified contradictory oscillator settings. You have the HS
fuse, which is for an external crystal (with capacitors). So presumably
you have a 16 MHz crystal connected to the PIC ? But then, in the
#use delay() statement, you specify the 'int' oscillator which tells the
compiler to use the INTRC_IO fuse. It overrides the 'HS' fuse setting.
This means that your crystal is not being used, and your oscillator
frequency is coming from the less accurate internal oscillator.
2. You said these are production units, but yet you have the 'ICD=TRUE'
device statement. That isn't normally done in production. Note the
warning inserted by the compiler at the end of the .LST file, quoted above.
Debug mode overrides some fuse settings. I don't know if you posted all
your #fuses or not, but I would never ship a unit with the code set for
debug mode.
| Quote: |
I've searched the forum and can't find anything similar to my problem |
Here is one previous thread on it. There may be more:
http://www.ccsinfo.com/forum/viewtopic.php?t=46968
But I don't see any conclusive explanation given, or a way to duplicate
the problem. So I don't know how much help that thread is.
| Quote: |
Unfortunately I did not back up the .lst files so I can't check to see if that
is identical to the one being produced today.
|
If you want to read the flash memory (assuming it's not code protected)
from your PIC and save out the disassembled listing so you can compare
it to another .LST file (manually, on printed sheets), this thread has
instructions on how to do it:
http://www.ccsinfo.com/forum/viewtopic.php?t=47778
And just in case it's applicable, here's a thread that discusses reasons
why code might run differently on what is apparently the "same" board:
http://www.ccsinfo.com/forum/viewtopic.php?t=19059 |
|
|
jgschmidt
Joined: 03 Dec 2008
Posts: 184
Location: Gresham, OR USA
|
| Thanks again for an excellent posting. |
| Posted: Wed Jul 04, 2012 10:49 am |
|
|
Dear PCM Programmer, and the many other expert responders,
I sincerely appreciate the effort, and often saintly patience, you put into your postings. While I usually don't have the initial problem that resulted in the postings, I always learn something useful from them. This one is just another excellent example.
Along with my morning coffee, the CCS forum is part of my daily routine, for I frequently find gems that will ease a project's frustrations.
Again, thank you all.
_________________
Jürgen
www.jgscraft.com |
|
|
picj1984
Joined: 01 Mar 2010
Posts: 73
|
|
| Posted: Thu Jul 05, 2012 11:25 am |
|
|
I too really, really appreciate the help.
I feel like I'm in some crazy bizarro world here.
In response to temtronic, your hypothesis is the same as mine. Just to be clear though, there is not a good .c file. Only a good .hex file. The .c file that was backed up during the time that things wore working correctly is identical to the .c file I am using now that is producing this buggy .hex file. I'm almost certain it's not something I did because the two c files are identical. I didn't upgrade the compiler or MPLAB or change anything to my knowledge. I checked windows update and there was a restore point at 6/21/12 but it's not letting me restore back to that point. I've never had luck getting system restore to work, something always goes wrong it seems.
In response to PCM programmer, the first thing I did was remove that HS fuse (I am using the internal oscillator) and comment out the 'ICD = TRUE' device statement. Then, I programmed a unit. Same buggyness though. Thank you very much for the information regarding those two thing.
I loved your idea of actually reading back the assembly language. I took a good unit and a bad unit (again, both, programmed with the same .c file to the very best of my knowledge) and read them into MPLAB in the manner you described. I used winmerge to look at the differences... hoping it'd be one silly little thing, but there are lots of differences. Most of the differences are small and look something like this:
| Code: |
1669 0684 00A7 MOVWF 0x27 // this is the bad one
1669 0684 00A8 MOVWF 0x28 // this is the good one
|
About 50% of the code is identical and the other 50% typically has small differences in the manner I described above. There is about a 10% section that seems to just have stuff in a different order than the other one.
I'm going to keep investigating and trying stuff. Please let me know if you guys have any other suggestions. Again, I can't underscore how appreciative I am.
Joel |
|
|
picj1984
Joined: 01 Mar 2010
Posts: 73
|
|
| Posted: Thu Jul 05, 2012 12:41 pm |
|
|
hey guys,
I found a bug that ultimately fixes everything. I have no other explanation besides it must have been something I absentmindedly put in after I loaded that code into the prototypes.
I'm sorry for wasting your time. I must be losing my mind. There are still lots of unanswered questions (in my mind), but the only rational conclusion is that it was something I absentmindedly did.
Thanks for everything - Joel |
|
|
picj1984
Joined: 01 Mar 2010
Posts: 73
|
|
| Posted: Thu Jul 05, 2012 1:53 pm |
|
|
I've answered all my unanswered questions. It was completely my doing. I inadvertently made a change in the code (that wrecked a bunch of stuff) after I loaded the firmware into the prototypes.
Long story short, everything did exactly what it was supposed to except for me.
Lesson learned.
Thanks again for the help! |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9226
Location: Greensville,Ontario
|
|
| Posted: Thu Jul 05, 2012 2:16 pm |
|
|
Heck I'm happy you FOUND the problem !! And in fairly short time....
It's easy to blame darn near everything except the programmer ('pilot error syndrome')..and with good reason...these things really are complicated even if just 40 pins !
Now you know why I have multiple backups of everything, splattered over 2 harddrives and a flashdrive. After 30+ years I do NOT trust these computers as far as I can toss them (yes I have....) |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
