There appears to be a minor problem setting the last byte of the configuration bits on 18f25k42 hex files.
I am currently writing and compiling my GCB programs using an Orange Pi Plus 2E (a single-board computer similar to a Raspberry Pi), then uploading them to the chip over the GPIO pins using a software program called Pickle (https://wiki.kewl.org/dokuwiki/projects:pickle). When I do, I get the following error:
I think this is because the last configuration byte on this chip according to the datasheet (http://ww1.microchip.com/downloads/en/DeviceDoc/PIC18LF24-25K42-Data-Sheet40001869C.pdf, page 64) is unused and read as 0xFF, but in the hex file it's 0x00.
The ConfigMask in the 18f25k42.dat device file has only 9 bytes while the chip has 10, so I added an extra '255' byte to it. That changed the error I got on writing to the chip to:
but verifying the hex file now produces no errors.
I believe this is a problem with the compiler, not the pickle programming software I'm using, because programs written in JAL don't produce this error.
Again, it's a minor issue, as the last configuration byte isn't used anyway. But the error left me confused when I first encountered it, and I thought there was something wrong with my setup.
FWIW, I'm using Great Cow BASIC (0.98.02 2018-05-16 (Linux))
-Jim
~ sent from my pedal-powered computer (pedalpc.com) ~
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for taking the time to look at this. You have a lot more experience with this than I do, so I could very well be wrong.
I've attached seven files: program.bas - simple blink LED program that generated the hex files program-orig.hex - compiler output using original .dat file dump-orig.hex - hex dump from chip after programming with program-orig.hex program-modified_dat.hex - compiler output using the modified .dat file dump-modified_dat.hex - hex dump from chip after programming with program-modified_dat.hex 18f25k42-orig.dat - original .dat file installed with the compiler
* 18f25k42-modified.dat - .dat file with extra 255 line added in [ConfigMask]
The problem, as I see it, is that there are 10 configuration bytes on this chip, but the last one is unused. It can be set to any value.
The original 18f25k42.dat uses a mask of 9 bytes, because the 10th byte doesn't matter. Hence, any program compiled using this file has the final configuration byte set as 0x00.
However, when the file is dumped from the chip using my programmer, the 10th byte is read as 0xFF. That result agrees with the datasheet ('unused bits are read as 1').
Adding a 10th byte of 0xFF to the configuration mask forces the compiler to write the final configuration byte as 0xFF, making it agree with the data dumped from the chip.
Sorry, Jim bu the bug is in the programmer software.
PICkitPlus, MPLAB-IPE and Northern programmer all program and validate the HEX as is with no modifications in the .dat or the compiler.
The is no high byte config word 5 - see DS40001836A page 27, see your programmer should assume 255 (0xFF) as the other programmers do. This would explain why the modification to the .dat would resolve - but, we would not advise changing the .dat but to fix the programmer.
:-(
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for pointing me to the programming specification sheet, but now I"m even more confused :(.
Page 27, as you noted, indicates there is no Configuration Word 5H. It's not among the register tables (B-1 to B-9) in this document, either.
But it is mentioned in the checksum calculations on pages 29-32, and it's listed in the register tables on the chip's data sheet (40001869C, page 64, Register 5-10).
The programmer I'm using is admitted not sophisticated. It goes strictly by what it reads in the hex files and reads back from the chip. It does no per-chip validation, other than comparing what it has written to what it reads back. So, when it reads the configuration line in the hex file from the compler:
:0A0000008FDF37FFEDFFFFFFFF0069
It sees the first byte (0A) as indicating their are 10 bytes of configuration registers, the last one being 0x00 (00). It doesn't assume this last byte should be 0xFF because it's not pre-programmed to know this.
When it reads this data back, it sees:
:0A0000008FDF37FFEDFFFFFFFFFF69
with the last byte being 0xFF because all the bits in the last configuration byte are unimplemented and read as 1 (per the Register 5-10 table referenced above). Because of the mis-match, it throws an error.
Is it interpreting this incorrectly, or are the other programmers handling this wrong? If there are only nine significant data bytes, shouldn't the leading byte be 0x09 instead of 0x0A? How could a programmer like mine handle this properly if it's not preprogrammed to know this?
Not trying to be a nuisance, just trying to understand how Microchip hex files are supposed to work. I've been using PICs on and off for a few years, but never dug into the details of their data file structure before, and view this as a learning opportunity. Thanks for all your help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As I have the source to the Microchip programmer software I will walk/debug how the last word is handled.... why? Cus, I dont the answer to you question. :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If that's going to be much work, Evan, don't bother--my programmer works fine as long as I overlook the error. I just thought this was either a simple bug in the compiler or something that my programmer was doing wrong.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Pickle have implemented the new protocols and they have forgotten to addess the this new protocol has flipped the bits on the wire for the config bits. So, all the bits are reversed on the wire. So, as they are flipping the bits they need to pad for the bits than could be missing.
I am 100% certain there is no fault in Great Cow BASIC - I did examine in the source, and, PICkit Plus then I looked at https://wiki.kewl.org/dokuwiki/projects:pickle. Pickle does not seem to support config masks then you would have ensure your source has the high byte (which becomes flipped low byte) for the new protocol.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There appears to be a minor problem setting the last byte of the configuration bits on 18f25k42 hex files.
I am currently writing and compiling my GCB programs using an Orange Pi Plus 2E (a single-board computer similar to a Raspberry Pi), then uploading them to the chip over the GPIO pins using a software program called Pickle (https://wiki.kewl.org/dokuwiki/projects:pickle). When I do, I get the following error:
but the uploaded program works fine. When I verify the integrity of the hex file on the chip against what was compiled, I get this error:
I think this is because the last configuration byte on this chip according to the datasheet (http://ww1.microchip.com/downloads/en/DeviceDoc/PIC18LF24-25K42-Data-Sheet40001869C.pdf, page 64) is unused and read as 0xFF, but in the hex file it's 0x00.
The ConfigMask in the 18f25k42.dat device file has only 9 bytes while the chip has 10, so I added an extra '255' byte to it. That changed the error I got on writing to the chip to:
but verifying the hex file now produces no errors.
I believe this is a problem with the compiler, not the pickle programming software I'm using, because programs written in JAL don't produce this error.
Again, it's a minor issue, as the last configuration byte isn't used anyway. But the error left me confused when I first encountered it, and I thought there was something wrong with my setup.
FWIW, I'm using Great Cow BASIC (0.98.02 2018-05-16 (Linux))
-Jim
~ sent from my pedal-powered computer (pedalpc.com) ~
Morning Jim,
I am not sure I agree, yet, with your analysis of the root cause.
Post your project please, as a zip attachment. I need to see you source. Please include the modified .dat file.
I am using the K42s extensively and not having these issues here.
Last edit: Anobium 2018-10-06
Hi Evan,
Thanks for taking the time to look at this. You have a lot more experience with this than I do, so I could very well be wrong.
I've attached seven files:
program.bas - simple blink LED program that generated the hex files
program-orig.hex - compiler output using original .dat file
dump-orig.hex - hex dump from chip after programming with program-orig.hex
program-modified_dat.hex - compiler output using the modified .dat file
dump-modified_dat.hex - hex dump from chip after programming with program-modified_dat.hex
18f25k42-orig.dat - original .dat file installed with the compiler
* 18f25k42-modified.dat - .dat file with extra 255 line added in [ConfigMask]
The problem, as I see it, is that there are 10 configuration bytes on this chip, but the last one is unused. It can be set to any value.
The original 18f25k42.dat uses a mask of 9 bytes, because the 10th byte doesn't matter. Hence, any program compiled using this file has the final configuration byte set as 0x00.
However, when the file is dumped from the chip using my programmer, the 10th byte is read as 0xFF. That result agrees with the datasheet ('unused bits are read as 1').
Adding a 10th byte of 0xFF to the configuration mask forces the compiler to write the final configuration byte as 0xFF, making it agree with the data dumped from the chip.
Sorry, Jim bu the bug is in the programmer software.
PICkitPlus, MPLAB-IPE and Northern programmer all program and validate the HEX as is with no modifications in the .dat or the compiler.
The is no high byte config word 5 - see DS40001836A page 27, see your programmer should assume 255 (0xFF) as the other programmers do. This would explain why the modification to the .dat would resolve - but, we would not advise changing the .dat but to fix the programmer.
:-(
Thanks for pointing me to the programming specification sheet, but now I"m even more confused :(.
Page 27, as you noted, indicates there is no Configuration Word 5H. It's not among the register tables (B-1 to B-9) in this document, either.
But it is mentioned in the checksum calculations on pages 29-32, and it's listed in the register tables on the chip's data sheet (40001869C, page 64, Register 5-10).
The programmer I'm using is admitted not sophisticated. It goes strictly by what it reads in the hex files and reads back from the chip. It does no per-chip validation, other than comparing what it has written to what it reads back. So, when it reads the configuration line in the hex file from the compler:
:0A0000008FDF37FFEDFFFFFFFF0069
It sees the first byte (0A) as indicating their are 10 bytes of configuration registers, the last one being 0x00 (00). It doesn't assume this last byte should be 0xFF because it's not pre-programmed to know this.
When it reads this data back, it sees:
:0A0000008FDF37FFEDFFFFFFFFFF69
with the last byte being 0xFF because all the bits in the last configuration byte are unimplemented and read as 1 (per the Register 5-10 table referenced above). Because of the mis-match, it throws an error.
Is it interpreting this incorrectly, or are the other programmers handling this wrong? If there are only nine significant data bytes, shouldn't the leading byte be 0x09 instead of 0x0A? How could a programmer like mine handle this properly if it's not preprogrammed to know this?
Not trying to be a nuisance, just trying to understand how Microchip hex files are supposed to work. I've been using PICs on and off for a few years, but never dug into the details of their data file structure before, and view this as a learning opportunity. Thanks for all your help.
As I have the source to the Microchip programmer software I will walk/debug how the last word is handled.... why? Cus, I dont the answer to you question. :-)
If that's going to be much work, Evan, don't bother--my programmer works fine as long as I overlook the error. I just thought this was either a simple bug in the compiler or something that my programmer was doing wrong.
The issue is with Pickle.
Pickle have implemented the new protocols and they have forgotten to addess the this new protocol has flipped the bits on the wire for the config bits. So, all the bits are reversed on the wire. So, as they are flipping the bits they need to pad for the bits than could be missing.
I am 100% certain there is no fault in Great Cow BASIC - I did examine in the source, and, PICkit Plus then I looked at https://wiki.kewl.org/dokuwiki/projects:pickle. Pickle does not seem to support config masks then you would have ensure your source has the high byte (which becomes flipped low byte) for the new protocol.
Thanks a lot for looking into this, Evan. I'll bring it up with Pickle's creator.
Darron (pickle's creator) has added a config mask fir the newer 18F devices. I've tried it out and it's working now.
I thought the bug was not here, :-)