使用Unified Bootloader Application 0.1.14和PIC16F18324寻址错误0xFE

嗨，丹尼，首先，感谢你提供的详细信息。第1点。）：NVMADR和NVMADT的PIC16F18324.H的定义是正确的（数据表4-4表。点2）：新的重置和中断向量对我来说似乎很好（如果您的引导加载程序没有占用更多的程序空间）超过0x000。在统一引导加载程序主机应用程序中，将地址乘以2是应该的方法。这也解决了我在我提到的线程中所提到的问题。看看你的附件，你使用了一个0x400的引导加载程序。将它改为0x800，0x4000内存大小太多了！当你使用0x8000之前，这只是使它更糟（PIC你只使用了4096字节的程序内存，所以结束地址是0x0FFF）。使用0x2000内存大小。实际上，你的PIC上的MCC Bootloader应该防止重写自己，检查函数“Read Effer（））。在最上面你应该看到这样的东西：第3点。）你可以做到。还可以提供多种方法来“跳转”到引导加载程序。例如，我实现了一个软件引导加载条目（从应用程序重写NexIsReType向量并执行一个软件ReSET（））。请记住，当损坏的固件闪现时，此解决方案失败。在这种情况下，你将无法进入你的引导加载程序了。出于这个原因，我另外实现了一个硬件条目（Bootloader检查一个低状态引脚，它是通过内部上拉来初始化的）。点4。我不认为这是必要的。点5。只要您将引导加载程序与主应用程序一起闪动，省略引导加载程序。配置是走的路。但是，如果你正在闪动Bootloader，那么你也需要配置。但是我想这很清楚。第6点。你也可以尝试重做你的修改，使用NVMAT而不是NVMDATA吗？你正在使用的PIC有相当少量的内存。在使用Bootloader时，应该考虑切换到更大的版本，因为这占用了整个程序内存的25%。如果这还不够，请参阅PIC16F18325，甚至PIC16F18326。



      以下为原文

    Hi Danny,
 
At first, thanks for the detailed Information you provided.
 
Point 1.):
The definitions from pic16f18324.h of NVMADR and NVMDAT are correct (See TABLE 4-4 of the datasheet).
 
Point 2.):
The new reset and interrupt vectors seem good to me (provided your bootloader does not take more program space than 0x0000 .. 0x03FFF).
Multiplying the addresses by 2  in the Unified Bootloader Host application should be the way to go. This also solved the issues I had as I stated in my thread you referred to.
Looking at your attachment you have used a bootloader offset of 0x400. Change that to 0x800, 0x4000 for the memory size is too much! When you used 0x8000 before, that was just making it worse (The PIC you are using only has 4096 Bytes of program memory, so end address is 0x0FFF). Use 0x2000 for the memory size.
 
Actually the MCC bootloader on your PIC should prevent overwriting itself, check the function 'Write_Flash()' . At the very top you should see something like this:

 
if ((NVMADR & 0x1FFF) < NEW_RESET_VECTOR)
{
    frame.data[0] = ERROR_ADDRESS_OUT_OF_RANGE;
    return (10);
}
 

 
Point 3.)
You can do that. You can also provide multiple ways to 'jump' to your bootloader. For example I implemented a software bootload entry (overwriting the NEW_RESET_VECTOR from the application and performing a software RESET()). Keep in mind though that this solution fails when a corrupted firmware has been flashed. In that case you wont be able to enter your bootloader anymore. For this reason I additionally implemented a hardware entry (bootloader checks for a low state pin which is initialised with internal pull-up on reset). 
 
Point 4.)
I don't think that is necessary.
 
Point 5.)
As long as you flash the bootloader together with your main application, omitting the bootloaders configuration is the way to go. If however you are flashing the bootloader stand alone, you will need the configuration as well.
But I guess that's clear.
 
Point 6.)
Can you also try to redo your changes and use NVMDAT instead of NVMDATA?
 
 
The PIC you are using has quite a small amount of memory. You should consider switching to a bigger version when using the bootloader, as this takes 25% of your overall program memory. If that is not enough, look at PIC16F18325 or even PIC16F18326.
 
Regards
Fabian
 
EDIT:
corrected error in bootloader address range.

嗨，Fabian，谢谢你的详细回答。2）我的一个愚蠢的错误。谢谢！使用0x800和0x2000为我工作。第6点）它对我起作用。再次感谢，祝你周末愉快，Doa。



      以下为原文

    Hi Fabian,
thanks for your detailed reply. 
 
Point 2)
What a stupid mistake from my side. Thanks a lot! 
Using 0x800 and 0x2000 works for me.
 
Point 6)
It works both ways for me. 
 
 
Thanks again and have a good weekend,
Doa
 
 

嗨，Doa，很高兴听到它现在起作用了。有时候人们会对显而易见的东西视而不见，尤其是当论坛中关于某个主题已经有很多混乱的时候。你以前使用DATL和DAH的修复实际上是指数据寄存器被定义为8位的设备。在设备特定的头文件中注册（指向与DATL相同的位置）。祝你周末愉快，Fabien。



      以下为原文

    Hi Doa,
 
good to hear that it works now.
Sometimes one just gets blind to the obvious, especially when there is already a lot of confusion around in the forums about a subject.
 
The fix you previously applied using DATL and DATH was actually meant for devices where the DATA register is defined as 8 bit register (pointing to the same location as DATL) in the device specific header file.
 
Good weekend to you as well,
Fabien
 
 

恭喜你的工作和做功课的强烈工作。FabianL对第2点的回答是“如何使它工作”的问题。主机不知道哪个设备在那里，并接受输入的值作为正确的内存大小。这是“为什么它这样做”：看看擦除命令并找到这个代码片段。if（（nvMAD＆&；0x7f）& gt；= Enthflash）代码试图擦除超出Pro的结尾。克空间。当上面的点2尝试了0x8000的程序大小时，它在0x1000之后命中了这个条款。应用程序区域的擦除是成功的，但是它命中了这个命令并中止了命令。在添加这个测试之前，程序计数器会滚动并擦除引导加载程序。显然，擦除命令永远不会被主机确认。主机超时并报告丢失的通信。至少这样，它不会擦除引导加载程序。



      以下为原文

    Congrats on getting it working and strong work on doing your homework first.
 
FabianL's answer to point 2 nails the "how to make it work" question.  The host doesn't know which device is out there and accepts the entered value as the proper memory size. 
 
This is the "why it did that":   Take a look at the Erase command and find this snippet of code.

for (uint16_t i=0; i < frame.data_length; i++)
{
    if ((NVMADR & 0x7F) >= END_FLASH)
    {
        frame.data[0] = ERROR_ADDRESS_OUT_OF_RANGE;
        return (10);
    }

 
The if ((NVMADR & 0x7F) >= END_FLASH) code tests for an attempt to erase beyond the end of program space.  When point 2 above tried a program size of 0x8000, it hit this clause after 0x1000.  The erase of the application area was successful, but it hit this and aborted the command.  Before we added this test the program counter would roll over and erase the bootloader.  Obviously the erase command would never be acknowledged to the host.  The host times out and reports lost communication.  At least this way it doesn't erase the bootloader.
 
 

“有趣的子句，感谢添加了一点信息。假设我在1：”NexyReStIdApple & lt；0x7f2）失败了，那么EraseElFlasyBlaskSigel& G.64 i知道这可能不是这样的，但是它不足以使用吗？费边主义



      以下为原文

    Interesting clause, thanks for adding that bit of information.
 
Am I right assuming that this fails when either:
1.) NEW_RESET_VECTOR < 0x7F
2.) ERASE_FLASH_BLOCKSIZE > 64
 
I know this is probably never the case but wouldn't it suffice to use:

if ((NVMADR & ((ERASE_FLASH_BLOCKSIZE << 1 ) - 1)) >= END_FLASH)

 
instead?
 
Regards
Fabian

请问一下你们是怎么 找到的上位机软件的bootloader 的上位机软件的？我找了很久都没找到