I am attempting to replace a PIC18F2550 in a project with a PIC18F26J50 which
offers more Flash and on-chip peripherals (through pin-mapping). It can also
use an internal oscillator eliminating the need for an external crystal. In
fact, it might be a good candidate for future versions of usbpicprog.
During coding of the Configuration Fuses I noticed a discrepancy between the
Datasheet description of the FOSC options and what usbpicprog reports i.e.
FOSC and FOSC2 (which appear to be incorrect).
Assuming the Datasheet is correct (?) and that I have been able to compile the
fuse settings using SDCC and gputils I wish to ask if usbpicprog just presents
its own interpretation of the fuses from the hexfile without any modification?
In other words, if I code the fuse settings in SDCC and gpasm generates an
error free hexfile will usbpicprog program the device to those values even if
it displays the fuse settings incorrectly?
Regards,
Neil Darlow
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
According to the datasheet, FOSC is 3 bits, in usbpicprog it is separated in FOSC(2 bit) and FOSC2 (1 bit). It would in fact work and take the settings from the hex file.
To be more consistent with the datasheet, I have changed the values in the datasheet.
The fixed xml file can be found in the repository: https://raw.githubusercontent.com/fransschreuder/usbpicprog/master/trunk/upp_wx/xml_data/18F26J50.xml
If you copy that in your usbpicprog application folder
(linux /usr/share/usbpicprog, Windows Program Files\Usbpicprog\xml_data\
You should have it matching with the datasheet.
Frans
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, with further examination the fuse hex values are correct. It appears that usbpicprog is not aware of the INTOSC option names and applies the EC/HS/PLL ones in their place.
I actually need to see that the hardware fuse handling is correct also. On these devices the fuses are stored at the top of Flash and copied into the Configuration area during hardware reset. I am not sure if that has software or programming implications.
Regards,
Neil Darlow
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
of which, besides the 18f26j50 I identified, only the 18f85j50 has an entry for the search fuse in the usbpicprog device files.
I guess I need to now identify the datasheets which represent all the listed devices and confirm that the fuse definitions do require attention.
Looking at the datasheet for the 18f26j50 I have a suspicion that there is a typographical error relating to the CPU divisor flag. The datasheet refers to it as CPDIV but I believe that it should be CPUDIV (this is what SDCC expects and it throws an error with CPDIV). JALv2 also expects CPUDIV which seems to confirm my suspicion.
Regards,
Neil Darlow
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I am attempting to replace a PIC18F2550 in a project with a PIC18F26J50 which
offers more Flash and on-chip peripherals (through pin-mapping). It can also
use an internal oscillator eliminating the need for an external crystal. In
fact, it might be a good candidate for future versions of usbpicprog.
During coding of the Configuration Fuses I noticed a discrepancy between the
Datasheet description of the FOSC options and what usbpicprog reports i.e.
FOSC and FOSC2 (which appear to be incorrect).
Assuming the Datasheet is correct (?) and that I have been able to compile the
fuse settings using SDCC and gputils I wish to ask if usbpicprog just presents
its own interpretation of the fuses from the hexfile without any modification?
In other words, if I code the fuse settings in SDCC and gpasm generates an
error free hexfile will usbpicprog program the device to those values even if
it displays the fuse settings incorrectly?
Regards,
Neil Darlow
Hello Neil Darlow,
According to the datasheet, FOSC is 3 bits, in usbpicprog it is separated in FOSC(2 bit) and FOSC2 (1 bit). It would in fact work and take the settings from the hex file.
To be more consistent with the datasheet, I have changed the values in the datasheet.
The fixed xml file can be found in the repository:
https://raw.githubusercontent.com/fransschreuder/usbpicprog/master/trunk/upp_wx/xml_data/18F26J50.xml
If you copy that in your usbpicprog application folder
(linux /usr/share/usbpicprog, Windows Program Files\Usbpicprog\xml_data\ You should have it matching with the datasheet.
Frans
Hi Frans,
Yes, with further examination the fuse hex values are correct. It appears that usbpicprog is not aware of the INTOSC option names and applies the EC/HS/PLL ones in their place.
I actually need to see that the hardware fuse handling is correct also. On these devices the fuses are stored at the top of Flash and copied into the Configuration area during hardware reset. I am not sure if that has software or programming implications.
Regards,
Neil Darlow
Hi,
I have grep'd the gputils headers for INTOSCPLLO in an attempt to determine if there are other devices requiring this attention.
The list I have resulting from this is:
18f24j11
18f24j50
18f25j11
18f25j50
18f26j11
18f26j13
18f26j50
18f26j53
18f27j13
18f27j53
18f44j11
18f44j50
18f45j11
18f45j50
18f46j11
18f46j13
18f46j50
18f46j53
18f47j13
18f47j53
18f65j50
18f66j11
18f66j16
18f66j50
18f66j55
18f66j90
18f66j93
18f67j11
18f67j50
18f67j90
18f67j93
18f85j50
18f86j11
18f86j16
18f86j50
18f86j55
18f86j72
18f86j90
18f86j93
18f87j11
18f87j50
18f87j72
18f87j90
18f87j93
18lf24j11
18lf24j50
18lf25j11
18lf25j50
18lf26j11
18lf26j13
18lf26j50
18lf26j53
18lf27j13
18lf27j53
18lf44j11
18lf44j50
18lf45j11
18lf45j50
18lf46j11
18lf46j13
18lf46j50
18lf46j53
18lf47j13
18lf47j53
of which, besides the 18f26j50 I identified, only the 18f85j50 has an entry for the search fuse in the usbpicprog device files.
I guess I need to now identify the datasheets which represent all the listed devices and confirm that the fuse definitions do require attention.
Looking at the datasheet for the 18f26j50 I have a suspicion that there is a typographical error relating to the CPU divisor flag. The datasheet refers to it as CPDIV but I believe that it should be CPUDIV (this is what SDCC expects and it throws an error with CPDIV). JALv2 also expects CPUDIV which seems to confirm my suspicion.
Regards,
Neil Darlow