#13 Bug in Write18FKx

[Pascal]

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:

for (i = k = 0; i < dim; i += 2) {
  if (memCODE[i] < 0xFF || memCODE[i + 1] < 0xFF) {
   ...

This leads to a difference between the i and k counters at the end of the write loop. If I deactivate this check, i and k are equal at the end of the loop...

[Pascal]

The problem is that for an uneven value of dim, the end check condition is missed because i increments in steps of 2 and the final packet is not written.

A solution may be to grow the buffer when its size is even:

  if (dim & 0x01) {
      memCODE[dim++] = 0xff;
    }

    for (i = k = 0; i < dim; i += 2) {
        ...
              if (j > DIMBUF - 8 || i == dim - 2) {
                 ...

[Pascal]

Hmm, this seems complicated.

'size' seems to be set in 'FileIO' and the buffer allocated there... Not sure where this adjustment is best made. And maybe this problem also occurs with other devices so that it should be solved somewhere 'globally' ?

Any advice from the code owner?

[Pascal]

I have fixed this by enforcing an even code size in FileIO for P18 devices, plus have incorporated various other fixes to support the Q84 types, specifically the 18F26Q84 that I have. This includes adding a new 'type 2' device (Q84) with more config words, and changing the hard-coded number of config words to CONFIGlen.

While working with the code, I have changed tabs with spaces and re-formatted some code because I found it very hard to read. Therefore, I unfortunately cannot provide a reasonable 'diff' and instead attach the modified files. Hopefully they are useful to porting these changes back to the original code.

[Alberto Maccioni]

Can you provide an example where dim is not even?

[Anonymous]

I unfortunately don't have the simple test cases anymore. But I ran them
with a debugger and also with "printf-debugging", and definitely found
this problem (not hitting the end conditions) while debugging a crash.

I am using the modified op now and it works flawlessly and is super-fast.

Here is a case where the code length is uneven (produced by XC8).

What maybe also was special about the hex file is that some 0xff were
omitted (some 'lines' were shorter).

Printing the hex file in more readable form, the end looks like this:

2e50 - fe d7 02 2e fc d7 00 d0 12 00 0d 0e e0 ec 16 f0
2e60 - 0a 0e e0 ec 16 f0 12 00 c8 0e 00 d0 e8 2e fd d7
2e70 - 12 00
2e74 - ff 00 11 00 4c

Hope this helps

On 03/07/2022 14.40, Alberto Maccioni wrote:

Can you provide an example where dim is not even?

---

[bugs:#13] https://sourceforge.net/p/openprogrammer/bugs/13/ Bug in
Write18FKx

Status: open
Group: No milestone
Created: Fri Jul 01, 2022 10:54 AM UTC by Pascal
Last Updated: Sun Jul 03, 2022 12:14 PM UTC
Owner: nobody

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:

|for(i=k=0;i<dim;i+=2){if(memCODE[i]<0xFF||memCODE[i + 1]<0xFF){...|

This leads to a difference between the i and k counters at the end of
the write loop. If I deactivate this check, i and k are equal at the end
of the loop...

---

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/openprogrammer/bugs/13/
https://sourceforge.net/p/openprogrammer/bugs/13/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/
https://sourceforge.net/auth/subscriptions/