search

radiomanV / TL866

Open source software for TL866
GNU General Public License v2.0
345 stars 80 forks source link

OSCCAL value not being read from the PIC12F508 #5

Closed zansatsu0 closed 7 years ago

zansatsu0 commented 7 years ago

@radiomanV,

I don't know if this is something you can help with. I'm not an engineer by any stretch. I recently got into flashing PIC chips for various purposes. Please forgive me if you are already aware of any of the below information regarding the PIC12F508, I'm still relatively new to PIC programming.

I was recently doing a project which uses the PIC12F508 and I noticed that the factory OSCCAL value defaults to '0FFF' when the PIC is read under wine. When the chip is flashed, the default OSCCAL value is overwritten with '0FFF'. This factory value should read something similar to '0CB6' and is unique to the individual chip. Without this value, the chip will not function.

In the case of the PIC12F508, the memory range to be programmed is '0000' through '01F8' with the OSCCAL value stored at '01FF'.

In Windows, this value is read and it is given under the "IC Configuration" section of the Config tab as the "Backup OSCCAL Word" as well as the "Reset Vector Word". The OSCCAL value on the chip can be restored by unchecking "Programming Reset Vector Byte Disable" and populating the "Reset Vector" text box when flashing a bin or hex file.

I don't know if this is something your DLL enables, but this is an essential feature for programming the PIC12F508. Without this feature functional under Linux, it makes restoring the value cumbersome. If this is a bug, a fix is possible, and it falls into your sphere of influence, it would be extremely useful to not have to boot into that dusty old Windows drive. If this is a matter of system configuration, any advice you could offer to make this functional would be very useful.

Thank you for your time.

radiomanV commented 7 years ago

Hi zansatsu0,

Well thank you for your findings, you're right i can reproduce your issue but this bug is not applying only to PIC12F508 but to all devices which have config/fuse bits. I was not aware about this.

After deep digging in the source code i discovered what was wrong. It was function prototypes variable type mismatch (int/bool/unsigned int) between minipro.exe and replacement functions implemented in my dll. It was necessary to disassembly(again) the minipro.exe executable to check the function prototypes and thanks to a good disassembler i think i figured out that bug. I have pushed the fix here; please recompile or use provided dll's. Thanks.

zansatsu0 commented 7 years ago

It works! That sir, is a thing of beauty. Thank you very much for the quick response! :)