PIC18F46K22配置位由引导加载程序更新

嗨，我认为一般来说，引导加载程序不应该更新配置位。在十六进制文件中，可能存在新的配置位，而且可能存在用于对引导加载程序本身进行编程的内存部分的新闪存内容。如果在新应用程序中出现错误，则这两者中的任何一个都被销毁。阳离子，则引导加载程序将不再工作，并且不能用于修复设备，甚至不能用于校正的应用程序映像或具有先前版本的备份的设备。因此，我认为引导加载程序应该忽略将更改配置位或引导加载程序的新十六进制文件的那些部分。映像。一些设备具有各种保护机制以避免有人窃取或覆盖程序代码，无论是用于制作盗版拷贝，还是由于错误。您的PIC18F46K22有许多代码保护位，并为程序存储器的各个块写入保护位，包括单独的写保护。ect位用于数据EEPROM、引导块和配置寄存器。参见数据表中的第24章。有一个用于协作寄存器的写保护位，表明可以将更新写入配置寄存器。您必须做什么。所有这些保护位都被定义为在擦除状态中禁用保护。将保护位编程为0将使保护激活。您可以使用硬件保护位来保护Bootloader免遭重写，但是如果您让bootloader程序广告传统的保护位，它可以保护应用程序映像免受Bootloader编程的新更新。当使用XC8进行编译和链接时，它将创建一个新版本的启动代码，以及源代码中的一个新的配置设置。新的启动代码可以适用于程序中的更改或在Apple PrimMA规范中。所有这些都将在Flash程序存储器中编程，当使用开发工具如皮卡3或ICD 3或生产程序（如PM3）时，启动代码不会对FLAS进行更改。H程序内容，当它在上电或任何其他重置后运行。问候，Mysil



      以下为原文

    Hi,
I think that in general, the bootloader should Not update Configuration bits.
In a hexfile, there may be new configuration bits, and there may also be new flash contents for the part of memory where the bootloader itself is programmed.
 
If either of these are destroyed by a mistake in the new application, then the bootloader will no longer work, 
and cannot be used to repair the device, not even with a corrected application image, or a with a backup of a previous version.
So I think the bootloader should ignore those parts of the new hexfile that will change configuration bits or the bootloader image.
 
Some devices have various protection mechanisms to avoid someone stealing or overwriting program code,
either for making pirate copies, or by mistake.
 
Your PIC18F46K22 have a number of code protect bits, and write protect bits for various blocks of program memory, including separate Write Protect bits for Data EEPROM, Boot block, and Configuration registers.
See chapter 24 in the datasheet.
 
That there is a Write protect bit for Coonfiguration registers, indicate that it is possible to write updates into configuration registers. You have to what to do.
 
All these protection bits are defined such that in the Erased state, protection is disabled.
Programming protection bits to 0 will make protection active.
You may use hardware protection bits to protect the Bootloader against overwriting, 
but if you let the bootloader program additional protection bits, it may protect the application image against a new  update beeing programmed by the bootloader.
 
When using XC8 for compiling and linking, it will create a new version of startup code, and also a new set of configuration settings from  #pragma config settings in your source code. 
The new startup code may be adapted to changes done in the program or in #pragma specifications.
All this will be programmed in Flash program memory when you use a development programmer tool like PICkit 3, or ICD 3,  or a production programmer like PM3.
 
The startup code will Not  do changes to flash  program content, when it run after power up or any other reset.
 
Regards,
   Mysil

嗨，你对配置位的编程太冒险了。我将从引导加载器中删除它。你知道是否有链接器选项不添加配置位，ID和EEPROM内容到十六进制文件？如果我不使用它，那么我就不需要它。新的启动代码和未更新的配置位之间是否存在潜在的冲突？问候，LA



      以下为原文

    Hi,
 
You are right programming of configuration bits is too risky. I will remove it from bootloader.
Do you know if there is linker option to NOT add CONFIGURATION BITS, ID and EEPROM content to hex file?
If I will not use it then I don't need it. 
 
Is there potential conflict between new startup code and not updated config bits?
 
Regards,
LA