| View previous topic :: View next topic |
| Author |
Message |
see2kor
Joined: 30 Oct 2006
Posts: 5
|
| Help !! RAM location gets corrupted |
 Posted: Wed Mar 28, 2007 3:43 am |
 |
|
Hi,
A RAM location in my code gets corrupted because an application variable and a library routine access the same RAM address !!!
Application variable:
| Code: | | unsigned char mo_ra[168]; // global variable. |
Library routine which accesses mo_ra[4] (location : 0x86) is
| Code: | | #use delay(clock=CLOCK_SPEED) |
mo_ra[4] gets corrupted after a call of the delay routine
 ; I verified it on an ICD;(Also verified it without using the ICD option)
Please let me know your thoughts on solving this issue !!
My enviroment details are:
i) I have declared #use delay (..) before the definition of char mo_ra [Not sure if this info is required]
ii) Compiler Version: PCH 4.012
iii) PIC 18F
iv) Currently my code has used up 74% of RAM 
Also, is there a simpler way to find such memory corruption issues apart from going through the lst file or testing...
Thanks In Advance,
Regards,
PS
Note: went through previous posts but did not find a similar case |
|
 |
Ttelmah
Guest
|
|
| Posted: Wed Mar 28, 2007 4:17 am |
|
|
Seriously, 4.012, is too early a V4 compiler to have much hope of working right. The V4 compilers, are only _just_ starting to produce usable code. Around the middle 4.02x, they started producing code that 'worked' for many things, but in the 4.01x versions, you were better off using 3.249 (still probably just about true, - the latest versions have introduced some new problems, but most old code does now work, though many of the 'new' features still have problems...).
Normally the way to detect such problem, is to look at the .sym file, but I'd suspect this is actually a bank selection 'error', in which case the data in this won't apply. Realistically, either download 3.249, or get a newer copy of V4.
Best Wishes |
|
|
see2kor
Joined: 30 Oct 2006
Posts: 5
|
|
| Posted: Thu Mar 29, 2007 4:13 am |
|
|
Hi,
Thankyou for your inputs...Will try to explore that option.
 I found an old post in the forum which talks about a similar problem http://www.ccsinfo.com/forum/viewtopic.php?p=65216&sid=31d5fd596adcec9c71d05cc53fb81354
The only difference as I understand is that in my case the delay code is not called inside a isr but a function...
Clip from my lst file:->
. | Code: | ................... #use delay(clock=CLOCK_SPEED)
*
001E: MOVLW 02
0020: MOVWF FEA
0022: MOVLW 86 -- this location falls under mo_ra[]
0024: MOVWF FE9 |
I felt that some part of my code must have triggered this behaviour from the compiler... 
Hoping to solve this soon... 
Thanks & Regards,
PS |
|
|
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
| Posted: Thu Mar 29, 2007 6:24 am |
|
|
We are willing to help you, but 80% chance that the error is caused by the 4.01x compiler version. The early v4.0xx versions are crap. Save yourself (and us) a lot of time by not using them. Check the v4 sticky thread in this forum for current v4 status.
If you have v4.012 than you should also have v3.249 as they were both in the download area at the same time. That version can still be downloaded but if your subscription expired and you forgot to download that older version you can ask CCS for it. v3.249 is the last known stable version and should be used for production quality software. If the error persists we will help you investigating the other possible error causes. |
|
|
Ttelmah
Guest
|
|
| Posted: Thu Mar 29, 2007 9:57 am |
|
|
| see2kor wrote: | Hi,
Clip from my lst file:->
. | Code: | ................... #use delay(clock=CLOCK_SPEED)
*
001E: MOVLW 02
0020: MOVWF FEA
0022: MOVLW 86 -- this location falls under mo_ra[]
0024: MOVWF FE9 |
I felt that some part of my code must have triggered this behaviour from the compiler...
Hoping to solve this soon...
Thanks & Regards,
PS |
As a comment though (I agree totally with trying 3.249), the code you show, _does not_ access address 0x86. It accesses 0x286. This is what the two lines above do (set the bank to '2'). As such 'location 0x86' would not be corrupted by the code shown...
Best Wishes |
|
|
see2kor
Joined: 30 Oct 2006
Posts: 5
|
|
| Posted: Thu Mar 29, 2007 11:25 pm |
|
|
Thankyou for your inputs...
Got the point  ...Have already initiated the process to update my CCS compiler....
Thanks Again for your prompt replies.... |
|
|
see2kor
Joined: 30 Oct 2006
Posts: 5
|
|
| Posted: Tue Apr 03, 2007 12:04 am |
|
|
Last time my lst file clip was wrong... 
Just found the correct lst file clip...
| Code: | .................... delay_ms(20);
02A0: MOVLW 14
02A2: MOVLB 2
02A4: MOVWF x88 -- location 0x88 also comes under mo_ra[]
02A6: MOVLB 0
02A8: RCALL 001E |
mo_ra[] addr range is 07C-123
Found the same problem with compiler 4.031 .... yet to test with 3.249
Regards, |
|
|
Ttelmah
Guest
|
|
| Posted: Tue Apr 03, 2007 2:20 am |
|
|
| see2kor wrote: | Last time my lst file clip was wrong...
Just found the correct lst file clip...
| Code: | .................... delay_ms(20);
02A0: MOVLW 14
02A2: MOVLB 2
02A4: MOVWF x88 -- location 0x88 also comes under mo_ra[]
02A6: MOVLB 0
02A8: RCALL 001E |
mo_ra[] addr range is 07C-123
Found the same problem with compiler 4.031 .... yet to test with 3.249
Regards, |
Again though, the code you show, does _not_ access address 0x88. It accesses 0x288. Well away from the array. This is what the 'movlb' instruction does. It selects bank _2_. So far, I have seen no code with the compiler clashing with the array...
Best Wishes |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
