write_program_memory PIC18F46k80 Bootloader

[tolliug]

Hello,

I am working on a CAN bus bootloader for a PIC18F46K80. HEX file is received through CAN bus (without line preamble and Checksum) by packets of 6 bytes at most and stored in a temp_buffer (i.e an int8 array).

I am trying to use write_program_memory like that:

[Ttelmah]

You need to rethink what you are doing.

Writes to the page boundary (every 64 bytes), trigger a block erase. This chip
does not support 'byte write' (most do). Writes can only be a 64byte block. To
write a byte in the middle of a block, requires one to read the entire block into
a 64byte buffer, change the single byte, and write all 64 bytes back. Uses a write life every time....
You code needs to be writing whole blocks otherwise you will be 'drinking' write
lives. The 'write life' of this chip is only 1K cycles.
When writing, the chip completely stops running, so your source code will need
to send a 64byte block, then pause for long enough for the write, before
proceeding.
Also since your size does not align to the write boundary every time, erases
won't occur...

[tolliug]

From datasheet of pic18F46k80 (section 7,0 page 125), erase block size is 64 bytes and write block size is also 64 bytes. From CCS compiler documentation, page 90:

[Ttelmah]

The key problem is using 6 bytes.

The write function, will erase a block, when you write to the first address in
the block. With 6 bytes, you are only going to hit the erase boundary, every
third block, so there will not be an erase for the intermediate two blocks.
Then as explained you have the issue of write life. If you write an entire
block of 64 bytes, this is a single write operation. If you write little numbers
of bytes, you use up a write life every time you do this.
This is why the example bootloader, uses a 64byte buffer, assembles all
the data to fit in this, then send an XOFF to stop the comms, and writes
this.
CAN doesn't have an XOFF, so you will have to have a pause in communication
instead, but you need to be doing the writes in 64byte blocks.

[tolliug]

I understand that and now create a 64 bytes array that I fill in with CAN data. however I still miss something because ROM is not update (my write method is wrong... and need to first understand why....)

[tolliug]

[Ttelmah]

Yes. Depends on your fuses. You need to check what fuses are actually being set, when the chip is programmed (look at the listing file - fuses are at the end).
CPB would protect the bootblock area. Depending on the size BBSIZ1K or BBSIZ2K, this could affect this area.
PROTECT would prevent the whole of the ROM from being written.
WRT would also protect it from being written.

As a comment, you do realise that setting 'received_size' to zero in your
function does nothing?.
This variable here is a _local copy_ if the value sent. Changing it here will
not affect the value outside. If you want to change the value outside, you
need to look at 'pass by reference', or sending a pointer, which can then allow
the function to change the value being passed.

The same applies to cpt_block.

[tolliug]

Here's the fuses:

[Ttelmah]

How are yow testing whether a write has occurred?.
In MPLAB for example, the 'program memory' window does not allow live
updates. Also if you debug the unlock sequence, it is invalidated by the
debugger. You have to run the unlock at full speed, and then read back the
program memory, to see that a write has occurred.

I just did a test program with this chip:

[tolliug]

I am testing the write behavior using ccsinfo debugging mode and an ICD-U64 programmer, maybe you are right this might be not possible while debugging...

I will try your test code.

[Ttelmah]

The key point is that the actual write must be run at full speed.

When you debug, if you single step, the 'debug executive' takes over after
each instruction is executed. The unlock sequence needed to make a write
actually happen, _requires_ that the sequence is uninterrupted. The
same is true for interrupts (must be disabled during the write).

[tolliug]

Hello Ttelmah, There's definitely something wrong with the way I try to update program memory.

I am using CCSInfo IDE and ICD-U64. To check if program memory has been updated I am running the boot loader in normal mode. It runs your sample code, then I attach the debugger and check the ROM windows.

This shows me address up to 0x1802... nothing at 0x2000.

[Ttelmah]

The CCS IDE defaults to only showing ROM memory that it knows it has
loaded. The CCSLoad program does the same. I've complained about this
to CCS, but so far no change....
This is one reason I end up having to use other debug tools (though these
then have their own issues for other things...).
Worst comes to the worst, just read the memory out with
read_program_memory, and display the RAM buffer from this to see what
is there.