I2C Bootloader PIC16

[Ttelmah]

If there is a CCSC.INI file, the compiler will read options from this. If this
exists it could be overriding the default, which is +O8hex
Now if this setting is wrong, most programmers will still accept the file
(they have a lot more code, and support for multiple formats), but the
bootloader won't.
So look if there is a ccsc.ini file.
If there is, see what it says (text editor).
The other possibility is your linux code is not sending the LSB.

[bastirn]

I don't have any CCSC.INI file so it should use the default config as you said.
About the i2c, I use linux bash command (i2cset / i2cget).

[bastirn]

To be more exact: after loading a new program with the bootloader i have this :

Picture of what i read after loading a program:
https://engie-my.sharepoint.com/:i:/p/gd5731/ETwUFkpJZBNCr5ZW3TqhBF8BR8vdG1On0CeCdqpNrlQl_g?e=pOMoN2

So it replace the first 8 bits (LSB) of the opcode with what i send on i2c. The 6 bits left seems to be modify between 1 and 9 in order.

[Ttelmah]

So, what options have you got in your I2Cset command?.
This affects massively how the output data is configured.

[bastirn]

Those command are provided in linux:
https://manpages.debian.org/buster/i2c-tools/i2cset.8.en.html
https://manpages.debian.org/buster/i2c-tools/i2cget.8.en.html

I have checked those commands with an oscilloscope and they look as it is indicated in the i2c_bootloader.h file:

[Ttelmah]

OK.

First before you call your 'get', you need to set the address to be used back
to where the data is written. It carries on incrementing.
Then I'd use the byte packet mode for all transmissions.

So:
i2cset -y 1 0x50 0x01 0x22 0x11 0x00 0x00 i
i2cset -y 1 0x50 0x02 0xFF 0x0F i

i2cset -y 1 0x50 0x01 0x22 0x11 0x00 0x00 i
i2cget -y 1 0x50 0x02 w

I'd probably suggest using i2Cdump to actually load a block of addresses
rather than working on single words like this.

[bastirn]

As you can see on the following picture, i use this command but the result is not as expected.

The window on the right is the read of the program memory that i made after thoose i2c command.

https://engie-my.sharepoint.com/:i:/p/gd5731/Efqyo35P64VAu1Y4rl72lOEBoXOBQe0chqzUpVAwXNlQcw?e=yFlqVo

I think the problem is somewhere else. Can i send you my program by mail so you will know excatly what is done.

[Ttelmah]

Why are you using -y?.
This overrides the bus synchronisation. Needed for EEPROM access.....

[Ttelmah]

I'd suspect you may have an issue with the turn round timing.

Now this driver is written to talk to things like chips, that can turn round
from a write transaction to a read transaction 'immediately'.
However on the PIC, the controller has to exit the interrupt and then get
back into the interrupt and load the byte before the next transaction can
occur. This is why when using a slave and master PIC together, it is vital
that the slave is running at least as fast as the master, or it cannot
load the byte in time for the master transaction.
Now the problem is that the I2Cget command loads the address byte,
command byte, and then automatically issues the bus restart, read
controller address, and starts to read. Your chip will need a pause of perhaps
20uSec between the read address, and actually being ready to send data.
Depending on the speed of your Linux system, this just won't be happening...
Result the address byte that is already in the control register on the
PIC gets sent back before a new byte is loaded... :(

[bastirn]

The i2cget isn't the most important problem i have. It is the i2cset because i need to see that the program memory of the PIC is modified to validate that the bootloader is working fine. I will try to replace the bash command by a c pre-compiled program.

Can you affirm that the file "rom_write.c" is compatible with a PIC 16LF1829 ?

[bastirn]

Hello,

I need some explanation about how work the command "write_program_memory" and what is needed to make it fully work for my PIC16LF1829.

I read the ccs manual carefully and i see a function "write_program_memory8" which only writes the LSB of the opcode. It perfectly describe my problem, i can't write the upper part of the opcode. I try this command, and, indeed it only modify the LSB. As the manual say:

"This function only writes the least significant byte
to each address in program memory. See write_program_memory() for a function that
can write all the data to each address in program memory."

I assume that I'm not using the function "write_program_memory" well.
Is there any particular config or way to use it.

Here is what i tried :

[Ttelmah]

Using the block based 'write_program_memory' function to just transfer
two bytes at a time, is a terrifyingly inefficient way of working. I'm perhaps
not surprised it has issues when used this way.

To write just two bytes, is handled much 'better' by the write_program_eeprom
function. On most chips I'd simply say 'use this'. However for some
(unknown)
reason, on your chip the erase_program_eeprom function is not present.
Now normally to use the write_program_eeprom, you need to erase every
64 bytes, and then use the write through this block. Then when you get to
the end of the block erase again. So the sequence is: