View previous topic :: View next topic |
Author |
Message |
RLScott
Joined: 10 Jul 2007 Posts: 465
|
|
Posted: Wed Apr 02, 2008 7:23 am |
|
|
ob5erver wrote: | ...when I does not use send char within the interrupts it works fine... |
Can you post the code that works fine?
Robert Scott
Real-Time Specialties |
|
|
ob5erver
Joined: 17 Oct 2007 Posts: 12
|
|
Posted: Sun Apr 06, 2008 9:15 am |
|
|
RLScott wrote: | ob5erver wrote: | ...when I does not use send char within the interrupts it works fine... |
Can you post the code that works fine?
Robert Scott
Real-Time Specialties |
After 3 weeks hard work I think I have found the were was the problem.
There is something wrong with memset function when it was called with size > 256. I have used it with 512. I don't know why but after that the call stack gets corrupted and then everything is starting to behave strange... |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Sun Apr 06, 2008 1:01 pm |
|
|
Quote: |
There is something wrong with memset function when it was called with
size > 256. I have used it with 512.
|
From the CCS manual:
Quote: |
MEMSET( )
Syntax: memset (destination, value, n)
Destination is a pointer to memory, value is a 8 bit int, n is a 8 bit int. |
http://www.ccsinfo.com/downloads/CReferenceManual.pdf |
|
|
ob5erver
Joined: 17 Oct 2007 Posts: 12
|
|
Posted: Sun Apr 06, 2008 1:12 pm |
|
|
PCM programmer wrote: | Quote: |
There is something wrong with memset function when it was called with
size > 256. I have used it with 512.
|
From the CCS manual:
Quote: |
MEMSET( )
Syntax: memset (destination, value, n)
Destination is a pointer to memory, value is a 8 bit int, n is a 8 bit int. |
http://www.ccsinfo.com/downloads/CReferenceManual.pdf |
Yes, I saw the help but I thought that it was obsolete or it is for PIC16, not for PIC18. If you open CCS's Stdlibm.h you will see in function calloc usage of memset with int16 size parameter. Also it is obvious for me that the function works with int16 for size because my buffer was set fully after memset, but why the stack get corrupted is still mystery for me... |
|
|
ckielstra
Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands
|
|
Posted: Sun Apr 06, 2008 4:13 pm |
|
|
Here is the assembly listing for the memset function in v4.057: Code: | 00004: MOVLB 2
00006: TSTFSZ x18
00008: BRA 0010
0000A: TSTFSZ x19
0000C: BRA 0012
0000E: BRA 001E
00010: INCF x19,F
00012: MOVFF 0,FEE
00016: DECFSZ x18,F
00018: BRA 0012
0001A: DECFSZ x19,F
0001C: BRA 0012
0001E: MOVLB 0
00020: RETLW 00 | Address 0x18 and 0x19 contain the 16 bit variable for the length to be set. So yes, the manual is outdated and the length was upgraded from an int8 to an int16.
Quote: | but why the stack get corrupted is still mystery for me... | I tested the memset function in v4.057 and there it functions as it should. The problem must be somewhere else in your program, most likely a pointer problem or you are writing somewhere outside array bounds. Check the symbol file for variables that are mapped into the same address space of the buffer you are initialising with memset. |
|
|
ob5erver
Joined: 17 Oct 2007 Posts: 12
|
|
Posted: Sun Apr 06, 2008 11:31 pm |
|
|
ckielstra wrote: | Here is the assembly listing for the memset function in v4.057: Code: | 00004: MOVLB 2
00006: TSTFSZ x18
00008: BRA 0010
0000A: TSTFSZ x19
0000C: BRA 0012
0000E: BRA 001E
00010: INCF x19,F
00012: MOVFF 0,FEE
00016: DECFSZ x18,F
00018: BRA 0012
0001A: DECFSZ x19,F
0001C: BRA 0012
0001E: MOVLB 0
00020: RETLW 00 | Address 0x18 and 0x19 contain the 16 bit variable for the length to be set. So yes, the manual is outdated and the length was upgraded from an int8 to an int16.
Quote: | but why the stack get corrupted is still mystery for me... | I tested the memset function in v4.057 and there it functions as it should. The problem must be somewhere else in your program, most likely a pointer problem or you are writing somewhere outside array bounds. Check the symbol file for variables that are mapped into the same address space of the buffer you are initialising with memset. |
Yes, as I said the function seems to work with int16. When I saw the sym file I realized that the addresses are correct. I saw the variables that get messed up by memset. They are positioned just after my block that I set with memset. I am using CCS 4.068. |
|
|
ckielstra
Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands
|
|
Posted: Mon Apr 07, 2008 12:08 am |
|
|
I don't have v4.068 so can't check the correct functioning of memset, but it seems unlikely to me that memset is the cause of your problems. Can you reproduce the problem in a small example program and post it here? |
|
|
Ttelmah Guest
|
|
Posted: Mon Apr 07, 2008 2:51 am |
|
|
Keywords. 'Positioned just after'. This is terrifyingly suspicious of an array access, or pointer access that is going just a little further than you think it is. Classic things would be forgetting that a string is one character longer than it appears to be, or that array indexes in C start at 0.
I agree with Ckielstra.
Best Wishes |
|
|
ob5erver
Joined: 17 Oct 2007 Posts: 12
|
|
Posted: Mon Apr 07, 2008 5:16 am |
|
|
Ttelmah wrote: | Keywords. 'Positioned just after'. This is terrifyingly suspicious of an array access, or pointer access that is going just a little further than you think it is. Classic things would be forgetting that a string is one character longer than it appears to be, or that array indexes in C start at 0.
I agree with Ckielstra.
Best Wishes |
Sounds like a good advice, but not for my problem.
My code was:
int8 myBlock[512];
memset(myBlock, 0, 450);
and this clears around 10 to 20 variables or more after myBlock's memory, but not every time. It starts to work in the beginning and after a while, the problem appears. I made my code as simple as possible just to reproduce and dig into the problem and this was the only line that changes the behavior of my program.
The problem is that I am not sure why it happens, I will try to investigate the asm listing in order to see what's going on really. |
|
|
|