Recent changes to bugs

Can't execute latest version of Opgui.exe

Anonymous — Thu, 05 Oct 2023 13:41:07 -0000

Downloaded latest Opgui, installed the latest release of GTK runtime (form the link in the readme) but when i try to execute the Opgui.exe i alkways get the missing "libgdk-3.0.dll" lib error.
I have no problem with the old release.

P.S. If it is possible remove dependencies for that version of GTK, it's heavly bugged and has a terrible bug with system PATH (The installer overwrites the entire PATH with it's own instead of adding itself alongside the other entries)

#13 Bug in Write18FKx

Alberto Maccioni — Tue, 05 Jul 2022 14:47:46 -0000

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/

#13 Bug in Write18FKx

Alberto Maccioni — Sun, 03 Jul 2022 12:40:53 -0000

Can you provide an example where dim is not even?

#12 Bug in read code for new PIC18F devices

Alberto Maccioni — Sun, 03 Jul 2022 12:19:19 -0000

status: open --> closed

#12 Bug in read code for new PIC18F devices

Alberto Maccioni — Sun, 03 Jul 2022 12:18:51 -0000

Not a bug.
Dim2 does not have the meaning you describe; you can look at the comment:
// dim2=if>0 use eeprom, size is automatic when reading DCI
So it is pointless to specify a value, as it is anyways read from the DCI area.
So the meaningful values are 0 and not 0 (I use 1).
To be more precise the comment should be:
// dim2=if>0 use eeprom, size is automatically determined by reading DCI
"Forcing config words" is not in that source file; please add another ticket with a test case.

#13 Bug in Write18FKx

Pascal — Fri, 01 Jul 2022 18:46:25 -0000

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.

#13 Bug in Write18FKx

Pascal — Fri, 01 Jul 2022 13:29:57 -0000

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?

#13 Bug in Write18FKx

Pascal — Fri, 01 Jul 2022 12:26:24 -0000

The problem is that for an uneven value of dim, the end check condition is missed 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) {
        ...

Bug in Write18FKx

Pascal — Fri, 01 Jul 2022 10:54:47 -0000

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...

Bug in read code for new PIC18F devices

Pascal — Fri, 01 Jul 2022 10:53:12 -0000

There is a bug in the read code for the "new" PIC18F devices:

progP18.c:1595:

void Read18FKx(int dim,int dim2,int options)

Here dim2 is the eeprom size in bytes.

There are several bugs (I think) related to this.

1) In the device table, for some devices there is a "1" for the dim2
value, for example here:

{"18F27Q43,18F47Q43,18F57Q43",
PIC18,8.5,1,
Read18FKx,{0x20000,1,0x10},0,
Write18FKx, {0x20000,0x400,0x10,0,0,0},0}, //128K, 1k, --, LV

The "1" for the read parameter should really be 0x400.

2) when dim2==0, the read function is supposed to take the EEPROM size
from the device config information stored in the PIC.

This is done in line 1753:

if(z<DIMBUF-2){
sizeEE=(bufferI[z+1]<<8)+bufferI[z+2];
PrintMessage1("EEPROM size: %d\r\n", sizeEE);
}

But then later down in the function, tests are made checking the value
of dim2 (which is set to 0 for automatic detection).

e.g. line 1899:

//*** read eeprom *****
if(dim2){ //EEPROM

Another thing that is not nice is that "Forcing config words" is printed
even when no config words are specified.... But this has no functional
consequence and is easily fixed.