question about page sizes for 18F26K22 and 18F27J13 [solved]

[teletype-guy]

Hey folks:

I have a question about how much rom to allocate for the loader for a couple of different chips.

For a 64KB 18F26K22 I am using, the docs say "7 pages at the end of memory, which may vary based on firmware version." Well, I'm not sure what the page size is and can't seem to get a straight answer. For some reason I had allocated 768 bytes, but now I can't find a reference for that number:
#org 0xFD00, 0xFFFF {} // allocate top 768-bytes out of 64K-bytes

I am also using a 128KB 18F27J13 and the docs say "the loader is in the 2nd-to-last page" (config stuff is up in the top page), so I should org 2 pages. But again I don't know how big that is in bytes.

When I used tinybootloader on an 18F2620 I just saved 256 bytes.

I see in the datasheets a reference to "64-byte blocks" -- is that a page? When I search for page, I end up in the footer of every, er "page" on the datasheet, and there are hundreds of those .

I'm not expecting to hit the ceiling but would like to define it properly. Can anyone give me an answer (in bytes) for my ORG defs? Thx.

---

an addendum to my previous post:

I looking at the hex files for the two chips' loaders, I see:

18F26K22 has intel-hex data starting at 0xFDC0 (:10FDC0000F01000E3A...), which is probably why I ORGed starting at 0xFD00.

18F27J13 has intel-hex data starting at 0xF800 (:10F80000700ED3124...)
I am further confused on this part as it has 128Kbytes of flash, and am unsure how the 64K-based address records in intel-hex get mapped higher. I seem to recall that they do but I have not dug into intel-hex format in years. I hope the loader is actually getting placed at 0x1F800 and not 0x0F800. Still not sure what to ORG for this part.

thanks for any insight.

---

OK, I think I answered my own question about the intel-hex files:

For the 18F26K22, I see a line that seems to define the "extended" start address of 0x0000 (:020000040000FA) before all records.

For the 18F27J1, I see a line that seems to define the "extended" start address of 0x0001 (:020000040001F9). This is before the loader data records, and after the stuff that is at zero for vectoring. So it must indeed be located starting at 0x1F800.

But I am still wondering how many bytes in a page...

[Mikael Gustavsson]

Enable debug mode in ds30 Loader and perform a write operation. The boot loader placement will be output in the textbox.

[teletype-guy]

Hi Mikael:

Awesome -- I love this bootloader. I enabled debug for my 18F27J13 code and during parse now see (near the end):
Bootloader start address: 0x1F800
Bootloader end address: 0x1FBFF

I had previously found the start address of 0x1F800 in the intel hex file (after deciphering the "extended" start address record). The problem I was still having was when I did a memory reservation ORG of:
#org 0x1F800, 0x1FFFF {}
I was getting an error. A call to CCS later, and I found that I NEEDED TO CHANGE THIS TO:
#org 0x1F800, 0x1FFF7 {}
since the last eight bytes are now config words on this micro. Duh.

But why is the loader so far down in flash when it only needs to avoid the 8 top bytes? Seems like it could start at 0x1F900 with no problem, as the other versions only take 700-or-so-bytes. But I'm not complaining, since it is unlikely I will hit anything near the 126K ceiling with the 18F27J13.

I also see that the debug output says "Flash page 0 is used, 0x00 - 0x3FF" so I guess that answers my original question about how large a page is. Is that 1K-per-page a microchip definition or a dsLoader definition?

Many thanks for making this bootloader available to everyone. It is the first time a programmer has been able to target pretty-much any pic, and not be at the mercy of whatever few supported micros were available for a gratis bootloader. For years I used an 18F876 loader, and then when I needed more rom found an 18F252 loader, and then an 18F2620 loader. But these all forced me to conform to the pics available and the clock speeds that were hard-coded in their bootloaders. Even though there was a learning curve with MPLAB with dsLoader, it is so nice to be able to not only target a specific chip, but also be able to set up any clock configuration, AND be able to add a bit of user code to handle chip errata situations. Thanks again.

[Mikael Gustavsson]

Thanks for the feedback.

You need to perform a write operation to make sure you get the correct values. Before communication has been established with the boot loader the GUI can only guess the boot loader properties.

The boot loader is placed in the second last page so that the user has the option to update the configuration bits.

I use the page term even for families and devices that doesn't have actual flash pages. A more correct/generic term would be erase size. And row size would be write size.