| View previous topic :: View next topic |
| Author |
Message |
mdiaz.tello
Joined: 07 Jul 2010
Posts: 4
|
| LST file and pic16f1827 freeze |
 Posted: Wed Jul 07, 2010 8:42 am |
 |
|
I am doing a project with the pic16F1827 and I have a question about the .lst file that gets output when I invoke the compiler. Specifically, I'd like to know how to interpret the "Stack" line within the file.
In my main.lst file it says the following:
| Code: | Filename: main.lst
ROM used: 1666 words (41%)
Largest free fragment is 2048
RAM used: 83 (22%) at main() level
118 (31%) worst case
Stack: 3 worst case (2 in main + 1 for interrupts)
|
The reason why I ask is because I am having a problem in my firmware where the main loop will just "freeze" after some number of minutes pass. In spite of this, the interrupts continue to trigger and their ISRs execute normally. This makes me think that perhaps the return address on the stack got screwed up somehow, and I want to try to understand what the LST file is telling me so I can see if my thoughts are correct.
Also, if anyone has an idea as to why the main loop would suddenly halt (despite the timer ISRs still executing), I'd appreciate your help.
Thanks! |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Wed Jul 07, 2010 10:34 am |
|
|
That PIC has 16 stack levels. The stack usage is OK in your program.
Look at the items in this post, both hardware and software.
Are you doing any of these things ?
http://www.ccsinfo.com/forum/viewtopic.php?t=41964&start=1
Because you are using interrupts, I would suspect #1 in the software section.
If this doesn't help, then post a small, compilable test program that
shows the problem. Also post your compiler version. |
|
|
mdiaz.tello
Joined: 07 Jul 2010
Posts: 4
|
|
| Posted: Wed Aug 04, 2010 12:30 pm |
|
|
Its been a little while since I posted last, but I determined that interrupts are not the source of the problem since global interrupts are only enabled at the start of main().
I tried connecting the debugger to the system to monitor what is happening, and I noticed that when it freezes, it happens just before executing a read_adc(). When I pause the system and then tell it to step over the function, it refuses to advance, which makes me think perhaps something is wrong with the read_adc() routine for this processor (PIC16F1827).
I am trying to run this program on a protoboard with just the micro on it so that I can post a version that you can use to confirm the bug.
Thanks for the help. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Wed Aug 04, 2010 1:21 pm |
|
|
| Also post your compiler version. |
|
|
mdiaz.tello
Joined: 07 Jul 2010
Posts: 4
|
|
| Posted: Wed Aug 04, 2010 1:23 pm |
|
|
Sorry.
The compiler says its version is 4.110. I know that the most current version that one can download is 4.109, but I spoke to tech support about problems with their setup_comparator routine and they sent me files that fixed that problem and now the compiler reports that it is version 4.110. |
|
|
mdiaz.tello
Joined: 07 Jul 2010
Posts: 4
|
|
| Posted: Thu Aug 05, 2010 9:50 am |
|
|
Well, I just had a look at the errata for this chip and there appears to be a problem with the A/D under certain conditions where it won't complete the conversion. If read_adc() is spinning while it waits for the conversion to complete, this could be the cause of the behavior I've observed. Has anyone else seen this problem on this chip?
I will post a sample program as soon as I am confident I can get the problem to trigger somewhere other than my PCB.
Thanks. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
