I believe that there is a bug in function Write18FKx:
void Write18FKx(int dim, int dim2, int options, int nu1, int nu2, int nu3)
"op" reports programming errors, and upon closer inspection these seem
to be related to "shortcuts" the function is taking by not programming
0xff bytes.
k is also adjusted in those "shortcut" cases.
Anyways, a test case is needed to reproduce and solve the issue.
I did try the algorithm on a 18F27Q43; but it could happen that a different hex file stimulates a different execution path with a so far undetected bug.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I believe that there is a bug in function Write18FKx:
void Write18FKx(int dim, int dim2, int options, int nu1, int nu2, int nu3)
"op" reports programming errors, and upon closer inspection these seem
to be related to "shortcuts" the function is taking by not programming
0xff bytes.
This concerns programming the Q43 types:
Here:
This leads to a difference between the i and k counters at the end of
the write loop.
This leaves me wondering whether the Q43 writing has actually been tested ?
k is also adjusted in those "shortcut" cases.
Anyways, a test case is needed to reproduce and solve the issue.
I did try the algorithm on a 18F27Q43; but it could happen that a different hex file stimulates a different execution path with a so far undetected bug.