![](templates/subSilver/images/CCSLogo.jpg) |
![CCS C Software and Maintenance Offers](templates/subSilver/images/forumAd6.jpg) |
View previous topic :: View next topic |
Author |
Message |
Guest
|
Behavior problems, can't figure it out! |
Posted: Wed Dec 01, 2004 2:49 pm |
|
|
Hi again,
I already posted this but my message was lost... Maybe I deleted it somehow, or my browser won't display it for some reason so sorry if this is a double post. Anyway, I have problems with my microcontroller:
- The system won't start
- Data from RAM is corrupted
- System hangs at some points and restarts
- and so on
With some compilations everything seems to work fine and with another compilation I get the weirdest errors. The strange thing is that these problems are sometimes gone when I add something as printf somewhere.
Somebody already helped me on this and suggested this was probably an error in the RAM such as buffer overflow, a pointer error or wrong type conversions. As for the type conversions, there are indeed errors in my code but I don't know for sure if I fix them right. For example:
Code: |
int8 test;
test = *pointer;
or
test = some16bitvalue;
|
I'm still not that experienced with C so is this fix right:
Code: |
test = (int8)(*pointer);
or
test = (int8)(some16bitvalue);
|
The problem is that their are thousands of lines to check. Anyone a smart technique to check this conversion errors fast?
But what I still find weird are the startup problems. A few posts back someone had a familiar problem and used #Build(reset=0x000) so I tried that as well but no result. And in the initialize fase I don't use any unsafe code as far as I know:
Code: |
void main()
{
disable_interrupts(GLOBAL);
restart_wdt();
delay_ms(1000);
restart_wdt();
fprintf( DB9, "\send something to rs232" );
|
if the printf statements doesn't even show up, what could be wrong?
My specs:
compiler picc 3.191
environment MPlab v6.60
No optimization used
MicroController PIC18F8720
128 k ROM
1k intern EEPROM, 8k extern
2 mb flash memory
8k sram
WebServer (GPRS, SMS, SMTP)
RS232 connection
Piece of the System setup:
#include <18f8720.h>
#device *=16
#fuses HS, NOPROTECT, BROWNOUT, WDT, WDT128, BORV45, PUT, STVREN, NODEBUG, NOLVP, NOWRT, NOWRTD, WAIT, MCU
#ID CHECKSUM
#ZERO_RAM
#device ADC=10
#define CPU_CLK 9830400 // Clock 9.830400MHz of 40000000MHz
#use DELAY(CLOCK=CPU_CLK, RESTART_WDT)
Greetings! |
|
![](templates/subSilver/images/spacer.gif) |
Guest
|
|
Posted: Wed Dec 01, 2004 3:05 pm |
|
|
In addition to the startup, I used #LOCATE, #BYTE or #BIT on ALL global variables. I commented the #LOCATE part and now it did start. That's not a garantee that the problem is fixed because it happened before with only a few #LOCATE instructions but I thought it might be usefull to figure out the problem. I used bank5,6,7,8,9,A,B,C,D,E and F completely. My RAM is 71..80%, sais the compiler.
Greetings |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Wed Dec 01, 2004 3:06 pm |
|
|
May I suggest:
1. Get rid of the Watchdog. Disable it. You don't need "random"
re-starts while you are debugging your program.
2. Once the watchdog is gone, now test your program and see if
it locks up. If it does, then put in printfs (or putc) statements
to show the progress of the program, and thus find where the
lockups are occurring.
3. Once you find the line of code that is locking up, then study it
and study the .LST file and data sheet, and find out why. |
|
![](templates/subSilver/images/spacer.gif) |
Guest
|
|
Posted: Wed Dec 01, 2004 4:11 pm |
|
|
Thanks for your help! I if I'm right, watchdog is removed by deleting WDT and WDT128 from the #fuses line. I also commented all restart_wdt() instructions. The system hangs at some point but its hard to figure out the exact point with printf's. Because when adding lines, the behavuar can change completely. For example, I was closing in on a hang-up point by adding more and more printf's. But then it suddenly hangs before all thos printf's, somewhere else.
I still think the data is corrupted somehow, the memory allocation is wrong or something like that. As I said, after removing all #LOCATE stuff the system suddenly started again. I don't use malloc as dynamic memory allocation isn't possible and its still weird that the system can crash without even executing some of the code. This error is making me insane! I'm struggling with it for weeks now. Anyway, thanks for your help!
Greetings |
|
![](templates/subSilver/images/spacer.gif) |
Humberto
Joined: 08 Sep 2003 Posts: 1215 Location: Buenos Aires, La Reina del Plata
|
|
Posted: Wed Dec 01, 2004 4:12 pm |
|
|
Code: |
void main()
{
disable_interrupts(GLOBAL);
restart_wdt();
delay_ms(1000);
restart_wdt();
fprintf( DB9, "\send something to rs232" );
|
Quote: |
if the printf statements doesn't even show up, what could be wrong?
|
You didnīt post the header line where should be defined the stdout for fprintf
#use rs232(baud=......., xmit=PIN_..., rcv=PIN_... , STREAM=DB9)
Best wishes,
Humberto |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
![](templates/subSilver/images/spacer.gif) |
Guest
|
|
Posted: Wed Dec 01, 2004 5:41 pm |
|
|
Thanks for the link! As someone said there, I've put all my global small variables (32 bits or below) in bank0, the array's are stored in bank 3 or higher. He suggested to do the same for the local variables, so I can just do something like this:
Code: |
void x{}
unsigned int8 test;
#LOCATE test 0x100
|
Bank 0 is full now so I'm forced to put local stuff in bank1. The other post about problems in the PIC18Fxx20 line is a little bit scary. I don't have much hardware knowledge as I'm just a simple student working for school right now but if I understand it right, changing some hardware may help a lot. I hope my boss will try this because I'm getting completely crazy with these bugs!
Thanks for the help guys! |
|
![](templates/subSilver/images/spacer.gif) |
Mark
Joined: 07 Sep 2003 Posts: 2838 Location: Atlanta, GA
|
|
Posted: Wed Dec 01, 2004 6:37 pm |
|
|
Quote: | Your problems seem very similar to the ones discussed in this thread:
This thread suggests going to the revision A4 silicon, and also some
other suggestions.
|
I am still getting fall out from the rev A3 Too many got out into the field! |
|
![](templates/subSilver/images/spacer.gif) |
|
|
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
|