怎么消除Bootloader额外的中断跳转

我希望NexIsReTypFig在Bootloader中是一个常量定义。如果是这样：主应用程序的中断表总是在同一个地方，而不是ISR本身。但是你可以自由地把ISR放在一个固定的位置（定位它绝对）。最好的（唯一的）位置是在应用程序的启动时-最终跟随程序入口地址或中断表。请注意，这样的绝对分配只适用于一个例程，除非您设法永远保持例程长度不变。（这就是为什么我们使用中断表：允许例程在长度上变化-而表本身具有恒定长度的条目）。



      以下为原文

    I expect NEW_RESET_VECTOR to be a constant definition within the bootloader.
If so: the interrupt table of the main application is always in the same place, but not the ISR itself.
But you are free to put the ISR to a fixed location (locating it absolute). The best (the only) location is at tze start of the application - eventually following the program entry address or the interrupt table. Be aware that such an absolute allocation works only for a single routine unless you manage to keep the routine length constant forever.
(This is why we use interrupt tables: to allow the routines to vary in length - while the table itself has constant-length entries.)

在这种情况下，代码偏移量为0x400。如果XC8 ISR在0x408，我可以直接跳到那里。ISR函数不需要是固定大小的。问题是ISR向量到0x00 04然后到0x0404，然后到应用程序ISR。



      以下为原文

    In this case the code offset is 0x400.
If the XC8 ISR was at say 0x408 I could jump straight there. The ISR function would not need to be a fixed size.
The issue is the ISR vectors to 0x0004 then to 0x0404 then to the application ISR.

看起来ISR处理器在0x0404。



      以下为原文

    It appears the ISR handler is at 0x0404

你可以做一些不同的事情：在0x000中找到应用程序的中断表。因为引导加载程序只使用重置向量，在从编程数据流中获取所有其他数据时，它必须保持这一点。数据混合方案。不是在照片上，但这没关系。



      以下为原文

    You could do some different thing: locate the application's interrupt table at 0x0000.
As the bootloader presumedly only uses the reset vector, it would have to preserve this while taking all other data from the programming data stream.
I really implemented such things some years ago, even "weirder" schemes of data mixing. Not on a PIC, but this doesn't matter.

PIC16复位和中断向量可以被移动。它们是硬件设置的。



      以下为原文

    The pic16 reset and interrupt vector can be moved. They are set in hardware.

PIC16FXXX，还是PIC16F1XXX？如果它是一个扩展的中程，那么你可以把汇编程序的指令放在你的引导程序中的位置0x00 04。如果它是一个标准的中值，你需要上下文保存代码（这个函数中的“中断”限定符），并且你必须返回到这里，这样它就可以完成CONTEX。T恢复，因为这些使用本地变量，或者，您的引导加载程序和应用程序必须强制使用上下文变量的相同位置。



      以下为原文

   
PIC16Fxxx, or PIC16F1xxx ?
 
 
If it's an extended midrange, then you can just put those assembler instructions at location 0x0004 in your bootloader.
If it's a standard midrange, you need the context save code here (which the "interrupt" qualifier on the function will add, and you MUST return back to here so it can do the context restore, as these use local variables,
OR, your bootloader and your application must be forced to use the same locations for the context variables.
 
Bottom line, extended midrange is MUCH easier to work with.
 
 

唯一标准的中值引导加载策略是一个高内存轮询引导程序。它必须用PaSeEL替换指令0x000到0x00，并跳转到引导加载程序入口点。原件被复制到高内存中，作为Bootloader退出例程，由PasiSell 0前缀，并用Goto 0x04加上Goto 0x05，以处理前四条指令不包含Goto到应用程序启动代码的情况。（Goto 0x00处理当原始指令0x00是测试和跳过的情况下，对于测试重置标志的汇编代码来说是可能的），只要应用程序代码从不跳转到地址0x00 1到0x00 3，它将处理应用程序代码，不管它是否使用中断向量。或者。拦截中断向量，因此它可以在引导加载程序中使用，这是不值得做的，因为它不能做得干净。



      以下为原文

    The only standard midrange bootloader strategy that's any good is a high memory polled bootloader.   It must replace instructions 0x000 to 0x003 with a pagesel and jump to the bootloader entry point.  The originals are copied into high memory as the bootloader exit routine, prefixed by a PAGESEL 0, and suffixed with GOTO 0x004 then GOTO 0x005 to handle the case where the first four instructions don't contain a GOTO to the application startup code.  (The GOTO 0x005 handles the case when original instruction 0x003 is a test and skip - possible for assembler code that is testing the reset flags)   As long as the application code never jumps to addresses 0x001 to 0x003, that will cope with application code whether or not it uses the interrupt vector.  Intercepting the interrupt vector so it can be used in the bootloader just isn't worth doing, as it cant be done cleanly.

为什么不使用/修改引导加载程序AN1310



      以下为原文

    Why not use/modify the Bootloader AN1310

这基本上是伊恩建议的，但是他又处理了更多的皱纹。



      以下为原文

    That's essentially what Ian suggested, but he handles a few more wrinkles.
 

N.B.还有一个‘GoTya’-如果擦除块大小大于4个字*并且编程失败，而在写入应用中断向量代码之前擦除块0，引导加载程序可以自己烧毁。为了最大化恢复的机会，引导加载程序首先擦除块1，并在最后擦除块0之前将程序跳到引导加载程序入口点，然后在重置向量上重新编程跳转到引导加载程序，并继续在R中编程应用程序代码。块0的EST，然后通过擦除和编程块1等来继续。这样，如果在块0被擦除或部分擦除但未被跳转到引导载入器入口点时，它中断（例如，失去电源或手动复位），则最大化了在块1中达到临时跳转到引导加载程序入口点的执行机会，从而避免了BR。您可以在Bootloader的第一个块下方的块的最后一个位置，将Bootloader状态标志作为ADDLW指令粗略地编程。用W 0跳转到它的值，通过引导加载程序开始返回。指令操作码为0x3FNN，闪存的擦除状态为0x3FFFF，因此应保留值0xFF以指示未能完成更新标志。可以使用其他值来指示应用程序代码的状态，或者用户可设置的引导加载程序选项。以这种方式存储多个标志字节也是可能的（尽管有点麻烦）——先读最后一个，然后在读下一个到最后一个，从返回的值中减去最后一个，甚至更早的，减去所有后续的和。在那个位置，但是在这种情况下，引导引导程序中的第一对指令应该处理丢失的ReLLW的情况。在一个操作中自动擦除较大块的设备上的标志处理策略更复杂——擦除块中的额外写入页将被设置为0x3FFF。可能需要一些实验来开发一个坚固的标志存储算法。*如果它的4或更少，引导加载程序就永远不需要删除包含有跳转到引导装载器入口点的重置向量的块0。



      以下为原文

    N.B. there is one more 'Gotya'  - if the erase block size is greater than 4 words* and programming fails while erasing block 0 prior to writing the application interrupt vector code, the bootloader can brick itself.  To maximise the chance of recovery, the bootloader should  first erase block 1  and program a jump to the bootloader entry point at the beginning of block 1 before finally erasing block 0, reprogramming the jump to bootloader at the reset vector and continuing to program the application code in the rest of block 0, then continuing by erasing and programming block 1 etc..  That way if its interrupted (e.g by loss of power or manual reset) when block 0 is erased or partially erased but not reprogrammed with the jump to the bootloader entry point, it maximises the chance of execution reaching the temporary jump to the bootloader entry point in block 1, thus avoiding bricking.
 
You can robustly program bootloader status flags as a ADDLW instruction in the last location of the block just below the first block of the bootloader. Jump to it with W 0 to read its value, returning via the start of the bootloader.  The instruction opcode is 0x3Fnn, and the erased state of the FLASH is 0x3FFFF, so the value 0xFF should be reserved to indicate failure to complete updating the flags.  Other values can be used, to indicate the status of the application code, or user settable bootloader options.  Its also possible (though a little cumbersome) to store multiple flag bytes this way - read the last one first, then when reading the next to last, subtract the last from the returned value, and for even earlier ones, subtract the sum of all subsequent ones.  
 
Alternatively store the flags in a RETLW at that location, but in that case the first couple of instructions just above it in the bootloader should handle the case of a missing RETLW. 
 
The strategy for handling flags on devices that do an auto-erase of a larger block than they can program in one operation is more complex - the extra write pages in the erase block will be set to 0x3FFF.  Some experimentation may be required to develop a rugged flag storage algorithm.
 
* If its 4 or less the bootloader never has to erase block 0 containing the reset vector programmed with the jump to the bootloader entry point

现在还不到100%。写入/擦除期间的功率损失可能导致部分写入或损坏数据。如果您想要100%（不计算其他地方可能发生的故障），则不应擦除在0x00上跳转到引导加载程序的原始指令。这意味着你永远不能删除矢量0x04（因为它是与0x00相同的页面）。中断向量不能包含任何可改变的代码，这几乎限制了它跳转到其他位置。简而言之，你要么有一些（当然很小的）砖块的风险，要么通过跳跃的持续时间增加你的中断延迟（2个循环&编辑和gt；或者如果y为3）。OO PaaSeel/Goto & lt；/Edg＆Gt；



      以下为原文

   


It is still not 100%. The loss of power during write/erase may result in partially written or corrupted data.
 
If you want 100% (not counting possible failures elsewhere), you should never erase the original instructions at 0x00 which jumps to the bootloader. This means that you can never erase the vector at 0x04 (because it is the same page as 0x00). Thus the interrupt vector cannot contain any changeable code, which pretty much restricts it to being a jump to some other location.
 
In short, you either have some (admittedly very small) risk of bricking, or you increase your interrupt latency by the duration of the jump (2 cycles or 3 if you do pagesel/goto).
 

你不能在重置中断向量中做任何形式的跳跃，除非引导装载器保留RAM来保存PCLATH的关键位，并调用重新定位的ISR，所以退出是通过你自己的上下文恢复代码——但是这会抛出堆栈级别，更不用说开销了。如果不允许重写块0，分析应用程序ISR和使用兼容上下文保存的选项是不可用的。然而，最坏的情况PIC16闪存擦除块大小不是那么大。最大值是32个单词。您可以简单地用NOP从0x04开始填充块0的其余部分，并使用BosisiZE-4的代码偏移，如前所述将前四个单词重定位到高内存，将真正的ISR入口点放在块1的第一个地址上，这样中断执行可以简单地通过NoP并在不增加上下文的情况下，进入ISR 28指令循环（32字BooCK大小）。当然，如果你的应用程序能容忍它的话，它会有很多额外的延迟。IMMO咬牙切齿，接受风险——尽你所能把它最小化——就像在开发过程中，你通常可以访问程序员，即使它不方便，而且一旦部署在这个领域，Flash UPDA就可以了。TES应该相当罕见，所以如果用户被警告要允许运行，那么总风险非常低。如果你不能接受风险，不要在一个“经典”的中档部分中设计并使用引导加载程序，因为增强的中程和PIC18都可以做干净的矢量重映射。错误向量



      以下为原文

    You *CANT* do any form of jump at the reset interrupt vector unless the bootloader reserves RAM to preserve the critical bits of PCLATH, and CALLs the relocated ISR so exit is via your own context restore code - but that throws away a stack level, not to mention the overhead.  The option to analyse the application ISR and use compatible context saving isn't available if you don't permit rewriting block 0.  
 
However the worst case PIC16 FLASH erase block size isn't that large.  IIRC the max is 32 words.  You could simply fill  the rest of block 0 from 0x04 onwards with NOP and use a CODEOFFSET of BlockSize-4, relocating the first four words to high memory as previously discussed, leaving the real ISR entry point right at the first address of block 1 so interrupt execution can simply run through the NOPs and drop into the ISR 28 instruction cycles later (for 32 word bloock size) without screwing up the context.  Sure its a lot of extra latency but its least evil if your application can tolerate that.
 
IMHO bite the bullet and accept the risk - do what you can to minimise it - as during development you usually have access to a programmer, even if it isn't convenient, and once deployed in the field, flash updates should be fairly rare so extremely low total risk if the user is warned they *MUST* be allowed to run to completion.  
 
If you cant accept the risk don't design in a 'classic' Midrange part AND use a bootloader, as both Enhanced Midrange and PIC18 can do clean vector remapping.
 
Edit: brainfart - I typed the wrong vector

你可能是指中断向量。在PIC16F1中，你可以做任何事情，因为中断会自动保存很多寄存器。当然，你可以使用“GOTO”。还有胸罩指令，不关心PCLATE。这就是PIC16F1比旧东西好得多的原因。我同意。当芯片易受攻击时，芯片在1ms内被烧毁的概率非常小。绝对少于你的用户在咖啡上泼咖啡的概率：



      以下为原文

   
 
You probably meant interrupt vector. In PIC16F1 you can do pretty much anything because interrupt automatically saves lots of registers. Definitely, you can use "goto". There's also the BRA instruction which doesn't care about PCLATH. This is what makes PIC16F1 so much better than the older stuff.
 



I agree. The probability that the chip gets bricked during that 1ms when it is vulnerable is very small. Definitely less than the probability of your user pouring coffee on the creature :)
 

对。我的意思是中断向量0x00。* * *＊＊＊＊＊＊＊＊＊＊没有破坏主程序，如果主程序都在第0页。PIC1XF1XXX（X）或PIC18是一个更好的选择，可能更便宜，当然更好的金钱价值。如果应用程序足够关键，你需要担心4ms漏洞窗口，那么WTF是否使用了近过时的“经典”中程14位内核？



      以下为原文

    Yes. I meant interrupt vector 0x004.   The *ONLY* way you can put a GOTO there without smashing the main program is if the main program is all in page 0.
 
PIC1xF1xxx(x) or PIC18 are a far better choice, probably cheaper, and certainly better value for money.   If the application is critical enough that you *need* to worry about the 4ms vulnerability window then WTF are  you using the near-obsolescent 'classic' Midrange 14 bit core?

我认为尼尔正在使用PIC16F1*之一。这里的Butter海报从不泄露特定的部分，XC8和MPLAX版本等LOL！！！！



      以下为原文

    I think Neil is using one of the PIC16F1*.
 
But posters here never divulge specific parts, XC8 and MPLAB X versions etc. LoL!!!

对不起，PIC16F1946（我的代码发誓我输入它）。在这种情况下，它是SPI，我使用芯片选择来强制Bootloader在电源上= BootLoad。因此，我不想跳到这个应用程序上。这个方法意味着它不能烧砖块。尽管如此，擦除块是32字节。但是我记得0x3FF。F是一个NOP。所以它可以将NoP编码到程序中。但是我注意到编译器编写者变得更聪明了。中断代码看起来是0x04 04，而不是一个跳转向量。这意味着没有额外的跳跃。现在有一个。不是我害怕的两个，所以我应该做一个胸罩而不是一个GOTO的中断？跳到主程序会怎么样呢？如果它们能写一个引导加载程序，并添加一个顶级引导程序的支持，这将是很好的。引导块保护选项是0x200，或者是内存的一半。太小了，或者太大了，奴隶的SPI太弱了。这是我的第一个SPI奴隶。SS引脚实际上是无用的。外部中断是一个更好的选择。



      以下为原文

    Sorry PIC16F1946 ( I code swear I typed it).
In this case It is SPI and I am using the Chip select to force the Bootloader Low on Power up = Bootload.
So I do not what to jump to the App on this one.
This method on this one means it can't brick.
even so the erase block is 32 bytes.
But as I recall 0x3FFF is a NOP. so it could coded to NOP into the program.
 
But I noticed that the Compiler writers have gotten smarter.
The Interrupt code appears to be at 0x0004, not a jump vector to it.  This means there is no extra Jump.  Well there is now the one. Not the two I feared. 
 
So should I be doing a BRA instead of a Goto for the interrupt? what about the jump to the Main Program.
 
It would be nice on these if they though about how one would write a bootloader.
And add support for a Top Bootloader.
The Boot block protect options are 0x200, or half the memory. To small, or too big.
And the Slave SPI is so weak. This is my first SPI slave.  the SS Pin is practically useless. The External Interrupt is a better choice.

文胸当然更好，但它的范围有限。如果你做GOTO，你也需要PasiSel.0x3FFF是“MOVIWFSR1[-1”），所以它会在FSR1指向的字节之前立即损坏字节。



      以下为原文

    BRA is certainly better, but it has limited reach. If you do GOTO, you also need PAGESEL.
 
0x3fff is "movwi FSR1[-1]" so it will corrupt the byte immediately before the byte that FSR1 is pointing at.

我想我会戴胸罩。它保存了一条指令。对0x3FFF感到羞愧。



      以下为原文

    I guess I will go with the BRA.
It saves an instruction.

A shame about the 0x3FFF.