| View previous topic :: View next topic |
| Author |
Message |
Martin Berriman
Joined: 08 Dec 2005
Posts: 66
Location: UK
|
| Memory confusion on PIC16F devices |
 Posted: Fri Apr 10, 2020 10:17 am |
 |
|
I'm using a PIC16F18445 at the moment. I've used many 18F parts with CCS but I'm struggling to understand the program memory usage with the 16F part.
The 16F18445 has 8k of program memory so up to 0x1FFF.
I can get code to run on the device so that's great however if I read the PIC using the CCS device programmer, the program memory appears to be twice the size I expect. The HEX file I download has code going up to 0x3FFF.
I must be missing something obvious - but what? |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Fri Apr 10, 2020 10:56 am |
|
|
| Hex files are in bytes. The program memory words are 14-bits in that PIC and take 2 bytes per word. |
|
|
Martin Berriman
Joined: 08 Dec 2005
Posts: 66
Location: UK
|
|
| Posted: Fri Apr 10, 2020 11:15 am |
|
|
| PCM programmer wrote: | | Hex files are in bytes. The program memory words are 14-bits in that PIC and take 2 bytes per word. |
Thank you, that makes sense.
I have however, as an experiment, written to the top of program memory via code having first reserved some space using:
#org (getenv("PROGRAM_MEMORY") - 8), (getenv("PROGRAM_MEMORY")) {}
When I read out the PIC, I find the bytes I have written appear just below 0x1FFF (i.e. around the middle of the HEX file), kind of as I'd expect, but there is code above them. So that makes me confused again... Could it be that getenv("PROGRAM_MEMORY") is the problem?
EDIT: Don't worry, it's me not reading the docs properly - getenv("PROGRAM_MEMORY") returns the number of words.
Last edited by Martin Berriman on Fri Apr 10, 2020 11:19 am; edited 1 time in total |
|
|
jeremiah
Joined: 20 Jul 2010
Posts: 1354
|
|
| Posted: Fri Apr 10, 2020 11:17 am |
|
|
| Martin Berriman wrote: | | PCM programmer wrote: | | Hex files are in bytes. The program memory words are 14-bits in that PIC and take 2 bytes per word. |
Thank you, that makes sense.
I have however, as an experiment, written to the top of program memory via code having first reserved some space using:
#org (getenv("PROGRAM_MEMORY") - 8), (getenv("PROGRAM_MEMORY")) {}
When I read out the PIC, I find the bytes I have written appear just below 0x1FFF (i.e. around the middle of the HEX file), kind of as I'd expect, but there is code above them. So that makes me confused again... Could it be that getenv("PROGRAM_MEMORY") is the problem? |
PIC's store a copy of the FUSES at the "very end" of program memory. PROGRAM_MEMORY returns the start of where those fuses are (so that you don't overwrite them by mistake) |
|
|
Martin Berriman
Joined: 08 Dec 2005
Posts: 66
Location: UK
|
|
| Posted: Fri Apr 10, 2020 11:21 am |
|
|
| jeremiah wrote: | | PIC's store a copy of the FUSES at the "very end" of program memory. PROGRAM_MEMORY returns the start of where those fuses are (so that you don't overwrite them by mistake) |
Thanks - for this PIC, the fuses seem to be at 8000 ish. Don't worry, I was misunderstanding the value getenv returned. |
|
|
jeremiah
Joined: 20 Jul 2010
Posts: 1354
|
|
| Posted: Fri Apr 10, 2020 11:26 am |
|
|
| Martin Berriman wrote: | | jeremiah wrote: | | PIC's store a copy of the FUSES at the "very end" of program memory. PROGRAM_MEMORY returns the start of where those fuses are (so that you don't overwrite them by mistake) |
Thanks - for this PIC, the fuses seem to be at 8000 ish. Don't worry, I was misunderstanding the value getenv returned. |
They are often times stored in two places: A copy at the end of program memory and the actual values later in memory (the 0x8000 you referenced). At power on, the PIC will load the copy (at the end of program memory) into the locations at 0x8000.
At least for the PIC24's. I haven't checked, but the PIC16's might be similar.
EDIT: An easy way to tell is if the value returned by PROGRAM_MEMORY ends in three 0's or not. If so, then it doesn't do the copy thing I mentioned and it is just the word vs byte issue. If the value it returns doesn't end in three 0's then it does have the copy of the fuses at the end of program memory as well. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
