search

radiomanV / TL866

Open source software for TL866
GNU General Public License v2.0
334 stars 79 forks source link

Disable code protection bit when generating a full firmware image in TL866_Updater. #21

Closed cr1901 closed 4 years ago

cr1901 commented 4 years ago

For purposes of open-tl866 development, I need a firmware with the CP0 bit disabled. What is the proper way to dump a "Full firmware" from the "Firmware" tab of TL866_Updater with CP0 bit disabled? In the "Hardware" tab, the "Advanced" section is "grayed out" and won't let me select the option where I recall it was possible to disable CP0.

Context/use case: I already have an external ICSP programmer; since I last worked on open-tl866, we now use the stock bootloader to load new payloads. So my original strategy of "using the entire PIC for the firmware payload and just disable CP0 unconditionally in the source" no longer applies.

This means I need an initial image that contains the bootloader with CP0 disabled so I can use my external programmer to selectively reprogram only the payload (as well as get access to debugging).

radiomanV commented 4 years ago

What is the proper way to dump a "Full firmware" from the "Firmware" tab of TL866_Updater with CP0 bit disabled?

In the firmware tab the generated firmware has the code protection bit set because of the latest firmwares from Autoelectric (starting with the 6.8x minipro version).
These versions (3.2.84/85/86) will detect the cp0 bit and will disable switch to bootloader function thus preventing further firmware upgrades. So sending the reset command to one of these firmware versions do nothing!
Any firmware version up to 3.2.82 (minipro V6.71) don't have this 'issue'

This means I need an initial image that contains the bootloader with CP0 disabled so I can use my external programmer to selectively reprogram only the payload (as well as get access to debugging).

For the sake of debugging and open spirit i have updated my firmware updater and now there's a checkbox in the firmware tab to disable cp0 bit in the generated firmware. The generated firmware version is 3.2.82. This is te last good version which don't verify the cp0 bit. So please be sure that after you disable the cp0 bit you don't upgrade to any of those x84/85/86 versions. You will not be able to switch to bootloader then.

In the "Hardware" tab, the "Advanced" section is "grayed out" and won't let me select the option where I recall it was possible to disable CP0.

The advanced button is only available when my custom firmware (aka firmware dumper) is flashed. So if you want to play then select the firmware dumper radio buton and reflash. Then the advanced buton will become available.

After you finish with this please flash the stock firmware back! but be careful to not put back one of those booby trap versions(84/85/86) and in the same time to have the cp0 bit disabled. Use the update.dat file from the minipro 6.71 version and you will be able to switch from the stock firmware to bootloader and back.

I hope that this will be useful for you.

cr1901 commented 4 years ago

@radiomanV Thank you very much for your quick response and commits. I am able to successfully get an image without code protection :D! I am closing as satisfied, the remaining comment is a minddump before I forget. To be clear, this is a great start, and hopefully in the future I'll be able to use the CP0 bit feature more, so thank you!:

I have determined at present that it is not possible to debug a payload with a bootloader present with Microchip's tools- the granularity they give you to preserve parts of the address space is not sufficient, not even from the command-line MDB debugger.

And even the times where I was able to preserve the bootloader (MPLAB IPE isn't exactly consistent on whether it works), I would get certain images that would show up as the MiniPro TL866 Bootloader when run, and then some images would never show up as a USB device.

From running a few rounds, the program memory on each image was identical, so maybe I had some config bits improperly set and the bootloader actually bothers to check before disconnecting as a USB device?