|
|
View previous topic :: View next topic |
Author |
Message |
Glen
Joined: 20 Mar 2010 Posts: 3
|
32K boundary problem... |
Posted: Sat Mar 20, 2010 9:13 pm |
|
|
I saw a couple of other posts that seemed to be a similar problem, but didn't see any definite resolution yet.
I am using an 18F4685 part, and v4.105 compiler. Everything was working fine until the code grew past 0x8000. Then the code above that address began acting very strange. On one of the other posts someone suggested it could be a problem with function calls on the 32k boundary and that using an #org to reserve the memory at the end of the first block might help. I tried that and it changed the problem but didn't fix it. Looking at the memory map, it seems the misbehaving code is entirely above 0x8000, not crossing the boundary. I commented out code until everything fit in the first 32k again, and the problem went away. It seems clear the problem occurs when the code grows larger than will fit in the first 32k. Has anyone else seen this issue? Am I missing something obvious? It seems like this is a fairly serious bug...
thanks,
Glen |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Sat Mar 20, 2010 11:31 pm |
|
|
Can the failure mode be demonstrated even if there is no external
hardware connected to the i/o pins (i.e., no motors, or relays, etc.) ?
Can you demonstrate a failure with just the serial port and a terminal
window on the PC ?
Can you demonstrate a failure only in hardware, or will it also fail in
MPLAB simulator ? |
|
|
loupan
Joined: 22 Oct 2007 Posts: 21
|
|
Posted: Wed Mar 31, 2010 8:40 am |
|
|
Hi,
PCM programmer suggested the org patch, and it fixed one problem, and moved it somewhere else.
I too noticed stange behavior but much over 64K. I am using an 18f8722 with 128k and the problem seemed to surface when the program grew > 100k.
It would be interesting if you can actually isolate the strange behavior with breakpoints and single stepping. I tediously did that a number of times to find that different addresses were being generated for the SAME function call.
I would be curious to see if that is your problem as well.
My original post is:
http://www.ccsinfo.com/forum/viewtopic.php?t=41396&highlight=
Another user appeared to have similar problems:
http://www.ccsinfo.com/forum/viewtopic.php?t=41702&highlight=
Please let me know if you can nail down the cause of your program's erratic behavior. If it is the same problem I am seeing, I would like to update CCS since they assure me that I am the only one having this problem.
Good luck. |
|
|
Glen
Joined: 20 Mar 2010 Posts: 3
|
|
Posted: Wed Mar 31, 2010 10:47 am |
|
|
Hi,
Yes, I saw your original post, that's what made me think this wasn't just my problem...
I looked at it further, and it seemed the problem was occurring when the code spanned the 0x8000 boundary. I put in an ORG 7800, 8100 which fixed it. ORG 7800, 8010 did not fix it. It does seem to be related to function calls across memory boundaries. I sent all this on to CCS but they have not been very helpful. Whatever I have sent them, more explanation, .LST files, etc., hasn't been exactly what they want...
Now if I see strange behavior from the code, I'm not sure whose problem it is.
I downloaded a copy of the HiTech C compiler to see how painful it would be to just switch, as this is getting frustrating trying to debug my code and the CCS compiler at the same time...
Glen |
|
|
|
|
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
|