PCD Hex has offset?

[Swys]

Hi all,

I am trying to write a wireless bootloader at the moment. I am using version 4.107 of the PCD compiler with a PIC24HJGP504.

Whenever I compile a program in MPLAB and I go to View -> Program Memory, I see that at the first memory location is a GOTO to 0x200 (as expected). But when I look at the HEX file, this GOTO points to 0x400, giving each address an offset of 0x200.

Can anyone tell me why this is, or give me a solution for this?

[Ttelmah]

Are you sure that is not just the difference between byte addresses, and word addresses?.....

Best Wishes

[Gary Smithson]

Ttelmah is correct. What you're seeing is the difference between the HEX file, which is always in terms of byte address, and the PIC24 which is in terms of word address.

I've just finished a PIC24 bootloader and hammered through these details. I can confirm that write_program_memory () and erase_program_memory () do work in version 4.107; but note that the parameters they require are word address rather than the byte addresses coming from the HEX file.

Gary

[Swys]

Thanks for the replies guys.

So, will it be enough for me to just subtract 0x200 from each address in the HEX file, since that is the final difference between the HEX file address and the PIC word address? Or is there something I'm missing?

Gary, can you please send me your bootloader code so I can have a look at it?

[Ttelmah]

There is no offset.
The 'point' is that 0x200 _words_, is 0x400 _bytes_. Intel hex format, is always in bytes.
If you start subtracting things the result will just be wrong...
If you want to know the word address being referred to, you just have to divide the byte address by two.

Best Wishes

[Gary Smithson]

If you were to observe other addresses randomly in the HEX file you would find that it is not an offset of 0x200. The HEX address is = PIC address * 2. Take the address from the HEX file and divide it by 2 before passing it to write_program_memory ().

I do apologize but the bootloader source is owned by my customer and I am not able to share it.

Bootloaders usually share large portions of core functionality. If you search this forum there are likely good examples. Also, there should be examples installed by CCS in the Examples directory.

Gary

[collink]

Just a quick note. The other posters are right about dividing by two. But, unless the compiler is really good at optimization you really should shift right one bit instead of dividing by two. That is:

WordAddress = ByteAddress >> 1;

instead of

WordAddress = ByteAddress / 2;

It's a small thing... I mean, they both do the same thing. But if you are going to divide or multiply by a multiple of two then it's more efficient to shift.

[Ttelmah]

Yes.
However CCS, is actually 'good' at this optimisation, and if you ask it to divide an integer by two, it will just perform the shift. Doing it yourself though, is always 'safer'.

Best Wishes

[Swys]

Great! Thank you all. I will implement this as soon as possible. I will put the address division in the software I will use to upload the firmware. I want the firmware to stay as generic as possible, so that I can use it with as little changes as possible whenever I use it with other PICs. But this leads to the following question:

Is it only the 16-bit PICs that use word addressing, or is this standard across the board?

[Swys]

Wait, I guess that was a stupid question. Am I right when I say that:

8-bit PICs use 1 byte for addressing,
16-bit PICs use 2 bytes for addressing (i.e. divide HEX address by 2) and
32-bit PICs use 3 bytes for addressing (i.e. divide HEX address by 3) ?

[FvM]

[Swys]

[collink]

[Swys]

Well now, that's quite embarrassing...

Anyway, yes, that's what I meant. But is it ok for me to do it that way...well, dividing by 4?

[Can't believe I missed that one...]