| View previous topic :: View next topic |
| Author |
Message |
pfournier
Joined: 30 Sep 2003
Posts: 89
|
| pcd_bootloader.h |
 Posted: Thu Dec 10, 2015 4:46 pm |
 |
|
In the drivers folder of the compiler 5.051 At the top of pcd_bootloader.h and loader_pcd.c LOADER_PAGES is defined.
Oddly enough they are given different values.
I am not sure what LOADER_PAGES are or if I need to adjust them.
Can anyone help me here?
pcd_bootloader.h
| Code: |
#ifndef LOADER_PAGES
#if getenv("FLASH_ERASE_SIZE") == 128
#define LOADER_PAGES 19
#else
#define LOADER_PAGES 2
#endif
#endif
|
loader_pcd.c
| Code: |
#ifndef LOADER_PAGES
#if getenv("FLASH_ERASE_SIZE") == 128
#define LOADER_PAGES 13
#else
#define LOADER_PAGES 1
#endif
#endif
|
_________________
-Pete |
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19550
|
|
| Posted: Fri Dec 11, 2015 2:17 am |
|
|
The loader must end on a page boundary.
Where this is, depends on how big the erase page is in the chip, and how large the loader is.
On PCD, they are doing it the opposite way round to the way they handle smaller chips. On smaller chips you specify the size of the loader, and you have to make sure that this is given as a number that is the last byte in a page. On PCD, you instead specify how many pages the loader needs. This is then used to calculate the 'size'. If you look a couple of lines later, it then uses these values to calculate the size if it is not specified.
On the PCD PIC's, there are just two erase page sizes used. 128 bytes and 2048 bytes. A program that needs 13*128 byte pages, can fit in a single 2048byte page. While one that needs 19*128 pages, requires 2*2048 byte pages. So the defines are handling these differences.
Just you confuse though the 'default' size specified in pcd_bootloader, is bigger, than is actually required by loader_pcd.c
If you look at loader_pcd.h, unlike the equivalent for the PIC16/18, it does not load the bootloader.h. So they are being a little naughty here with two different sets of code... :(
So you should specify LOADER_PAGES, choosing a value that is big enough for your bootloader, and your chip. If you do this before you load pcd_bootloader.h, it will then result in the automatic definition of 'LOADER_SIZE', and things being located correctly for both the bootloader and the program. Whoever wrote loader_pcd.c, appears not to know how CCS handle bootloader.h... Not good. |
|
|
pfournier
Joined: 30 Sep 2003
Posts: 89
|
|
| Posted: Fri Dec 11, 2015 7:58 am |
|
|
Thanks. Having it end on the border of an erase page makes total sense, otherwise you might need to read in the last page of the bootloader, erase, add code from the application to the saved page and write it all back. That puts the bootloader at risk of corruption and complicates the code.
I also discovered that getenv("PROGRAM_MEMORY"), which is defined in the help file as "Returns the size of memory for code (in words)" actually included the vector tables at the top. I was looking at the memory map in the Microchip documents and I was expecting the return to be the space between the end of the vector tables end of the the end of the program memory. Threw me off for a while.
While I am at it, does getenv("PROGRAM_MEMORY") really return words? It looks to me like it is bytes.
_________________
-Pete |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19550
|
|
| Posted: Fri Dec 11, 2015 10:28 am |
|
|
The vector tables are normally at the bottom.....
GOTO
Reset vector
Interrupt vector table
Gap (depending on the number of interrupts supported)
Alternate vector table
Code memory
Config words
The vector tables are part of the program memory, and in fact you can even use the area if you are not using interrupts (though it gets complex....).
The call returns the size _up to the config words_. They use the same addressing as MicroChip do in the data sheet, so it is a byte size. |
|
|
pfournier
Joined: 30 Sep 2003
Posts: 89
|
|
| Posted: Fri Dec 11, 2015 11:53 am |
|
|
Interestingly in pcd_bootloader.h if you don't define BOOTLOADER_AT_START there is this section of code:
pcd_bootloader.h
| Code: |
#if ((getenv("PROGRAM_MEMORY") % (getenv("FLASH_ERASE_SIZE")/2)) !=0 )
#define LOADER_SIZE (((getenv("PROGRAM_MEMORY") % (getenv("FLASH_ERASE_SIZE")/2)) - 1) + ((LOADER_PAGES - 1) * (getenv("FLASH_ERASE_SIZE")/2)))
#else
#define LOADER_SIZE ((LOADER_PAGES * (getenv("FLASH_ERASE_SIZE")/2)) - 1)
#endif
#define LOADER_END (getenv("PROGRAM_MEMORY") - 1)
#define LOADER_ADDR (LOADER_END - LOADER_SIZE)
|
where (getenv("FLASH_ERASE_SIZE")/2) is used with (getenv("PROGRAM_MEMORY").
I am assuming FLASH_ERASE_SIZE is divided by 2 to get the value in words, but then PROGRAM_MEMORY is used as is, even though it seems to in bytes as well.
On top of that APPLICATION_START and APPLICATION_ISR_START are not defined if you don't define BOOTLOADER_AT_START.
_________________
-Pete |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19550
|
|
| Posted: Fri Dec 11, 2015 12:04 pm |
|
|
Do yourself a two line program:
| Code: |
int32 size;
size=getenv("PROGRAM_MEMORY");
|
Obviously with a suitable 'main' round it.
Then just look at the .lst file. The variable will be loaded with a literal #xxxx, so you can tell at once how the size is generated.
On a 24FJ48GA004 for example, you will find it loads #ABF8. Given this has 48K bytes of program memory, this is the size in bytes. |
|
|
pfournier
Joined: 30 Sep 2003
Posts: 89
|
|
| Posted: Fri Dec 11, 2015 3:35 pm |
|
|
I've already done that.
What the real question is, is this line from pcd_bootloader.h
| Code: |
#define LOADER_SIZE (((getenv("PROGRAM_MEMORY") % (getenv("FLASH_ERASE_SIZE")/2)) - 1) + ((LOADER_PAGES - 1) * (getenv("FLASH_ERASE_SIZE")/2)))
|
I am assuming FLASH_ERASE_SIZE is divided by 2 to get the value in words, but then PROGRAM_MEMORY is used as is, even though it is in bytes.
So they are doing a calculation where part of it is: BYTES % WORDS. I would think you would want to do the modulus with values being both word or both byte. There may be a reason for doing this, but I don't see it.
ALSO in the help file, getenv("PROGRAM_MEMORY"), is defined as "Returns the size of memory for code (in words)". I hate it when the manual and reality disagree!
_________________
-Pete |
|
|
jeremiah
Joined: 20 Jul 2010
Posts: 1357
|
|
| Posted: Fri Dec 11, 2015 4:54 pm |
|
|
It does provide the program memory size in words. In particular it provides the start of the fuses (which leaves it up to the programmer to figure out what page that is so you don't write code to that page from the bootloader).
If you look at the value supplied by getenv("Program_Memory") for the PIC24FJ48004, it says it is 33788 which is 0x83FC (tested this with PCWHD v5.050). This aligns with both the diagram and the table in section 4 of the data sheet (Figure 4.1 and Table 4.1), which call those values out as word addresses. The PIC24 series has some funky math to convert the 48k bytes into addressable words. Section 4 has a lot of details on this.
Test program:
| Code: |
#include <24fj48ga004.h>
#warning getenv("PROGRAM_MEMORY")
void main(void) {
while(TRUE);
}
|
output:
| Code: |
>>> Warning 224 "pic24_test.c" Line 6(1,2): #warning 33788
Memory usage: ROM=2% RAM=2% - 2%
0 Errors, 1 Warnings.
Build Successful.
|
|
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19550
|
|
| Posted: Sat Dec 12, 2015 2:20 am |
|
|
The reason is to do with how the memory is actually organised. It is not:
'A block of continuous memory'.
Instead it is arranged like this:
Address 2 bytes
Address+2 1 byte
Address+4 2 bytes
Address+6 1 byte
There are only 3 bytes present, for every 4 byte addresses.
Using 16bit addressing, you get:
16bit Addr 16bit word
16bit Addr+1 8bit word
etc.
So the 'address range' available, exceeds the number of bytes actually 'present'.
The only way to really work safely, is in 'instructions'. This is the 'funky maths'..... |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
