CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support

Behavior problems, can't figure it out!

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
Guest








Behavior problems, can't figure it out!
PostPosted: Wed Dec 01, 2004 2:49 pm     Reply with quote

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!
Guest








PostPosted: Wed Dec 01, 2004 3:05 pm     Reply with quote

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
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Wed Dec 01, 2004 3:06 pm     Reply with quote

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.
Guest








PostPosted: Wed Dec 01, 2004 4:11 pm     Reply with quote

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
Humberto



Joined: 08 Sep 2003
Posts: 1215
Location: Buenos Aires, La Reina del Plata

View user's profile Send private message

PostPosted: Wed Dec 01, 2004 4:12 pm     Reply with quote

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
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Wed Dec 01, 2004 4:23 pm     Reply with 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.
http://www.ccsinfo.com/forum/viewtopic.php?t=19749&highlight=18f8720
Guest








PostPosted: Wed Dec 01, 2004 5:41 pm     Reply with quote

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!
Mark



Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA

View user's profile Send private message Send e-mail

PostPosted: Wed Dec 01, 2004 6:37 pm     Reply with quote

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 Mad Too many got out into the field!
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
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