dspic33EP256MC204上的BootLoader不能在MCU中实现

EZBL是我看到的第一份文件之一。但是，我觉得合并它和我的项目太难了。另外，我已经有了固件升级的软件和协议。公司规则…关于ISR，我想我需要在Bootloader和主应用程序上这是我考虑重新映射的原因。



      以下为原文

    The EZBL was one of the first documents that I saw. But I it looks too dificult to merge it and my project.
Also, I already have a software and a protocol to follow in firmware upgrades. Company rules...
 
About ISR´s, I think I need them on both - bootloader and main application - that´s the reason I thought about remapping.

“公司规则”和“公司工具”应该“在必要时改变”，但是EZBL也可以适应。Bootloader和应用程序可以共享相同的中断，但这增加了复杂性，并减慢了软件的执行。我没有追踪哪些衍生工具是IVT重映功能。可能是因为DSPIC33设备的性能更高，这是肯定的：从零开始是最坏的情况。



      以下为原文

    "Company rules" and "company tools" should be "subject to change when necessary".
But EZBL can be adapted as well.
Bootloader and application can share the same interrupt, but this adds to complexity and slows down software execution. I didn't track which derivatives sport the IVT remapping feature. Could be that it was dropped due to the higher performance of dsPIC33E devices.
 
One for sure: starting from scratch is the worst-case scenario.

您不会将引导加载程序合并到项目中。引导加载程序和应用程序是分开的项目。他们彼此很亲近。它们占据不同的闪光灯位置。你的Bootloader应该做什么让你认为它需要使用中断？这通常是不需要的。请注意，有几个PIC24变体具有交替的IVT。这将允许您在引导加载程序中使用中断。



      以下为原文

    You do not merge the bootloader in to your project. The bootloader and applications are seperate projects. The are inddepenant from each other. They occupy different flash locations.
What is your bootloader supposed to do that makes you think it needs to use interrupts? It is usually not required.
Note there are several pic24 variants that have an alternate IVT. That would allow you to use interrupts in the bootloader.

我想是一样的，但现在不是……我想这比写一个引导程序更糟糕。在我的例子中，我认为2或3个“Goto”不会慢下来，这是个问题…几乎所有的代码源都有AIVT和/或辅助闪存。而我的MCU，不是！我必须处理一个HMI（I2C）和一个UART。UART使用专有串行协议来接收新固件，我不能改变MCU。电机控制设备和成本问题。



      以下为原文

   
I think the same, but not now...
 

I think it would be worst than write a bootloader... In my case.
 

I suppose that 2 or 3 "goto´s" won´t slow down so much. 
 

 

That´s a problem... Almost all examples an code sources have AIVT´s and/or Auxiliary Flash. And my MCU, not!
 

I have to deal with a HMI (I2C) and a UART. The UART uses a proprietary serial protocol to receive the new firmware.
 

I can´t change the MCU. Motor control appliance and cost issues.

在SW更新期间HMI？说真的？



      以下为原文

   
HMI DURING the SW-Update? Honestly ?

为什么不？我想显示状态和/或错误。好，在擦除/编程步骤中我什么也看不出来，但我认为合理地显示一些信息来指导/建议用户。



      以下为原文

   
Why not? I want to show status and/or errors.
OK, I could show nothing during the erasing/programing step, but I think is reasonable show some messages to instruct/advise the user.

为什么不呢？最终用户需要一个可靠的引导加载程序，它从不积木。你有很多自我约束的限制，还有什么要补充的？如果它是你的第一个引导程序，并且正在推动你的技能水平，那么开始简单。你可以试着在它工作之后加上铃铛和哨子。



      以下为原文

    Why not?
The end user wants a reliable bootloader that never bricks. You have a lot of self imposed limitations and what to add more? If it your first bootloader , and is pushing you skill level , then start simple. You can try adding bells and whistles after it works.

当然，我开始使用3闪烁LED LED使用Time1 ISR。在Bootloader和主应用程序中。我可以看到从Bootloader过渡到主应用程序（通过改变闪烁速度），但是我不能看到Time1 ISR在主应用程序上工作，只在Bootloader上工作。这就是为什么我要问IVT重新映射的原因。如果我能重定向一个简单的计时器ISR，我可以重定向I2C或UART ISR s。



      以下为原文

   
Sure, I´m starting with 3 blinking LED´s using Timer1 ISR.  In bootloader and in main app. I can see the transition from bootloader to main app (by changing blinking speed), but I cant see the Timer1 ISR working on main app, only on bootloader.
That is why I´m asking about IVT remapping. If I could redirect a simple Timer ISR I could redirect I2C or UART ISR´s.
 

本质上，ISR重新映射并不太困难——即使没有IVT重新映射支持：也可以考虑IVT的引导加载程序的“拥有”。在某个常量地址定义应用程序的IVT区域。使引导程序“知道”它是活动的还是被动的（例如在某个变量上使用一些变量）。Bootloader的ISRS是“真正的ISRS”——提供输入/退出代码。应用程序的ISRS是形式简单的函数VaR ISR（Value-），尽管它们的地址必须存储在应用程序的“IVT”中。当发生中断时，引导加载器的I。SR必须检查是否调用应用程序的ISR函数（如果引导加载程序是被动的）或执行引导加载程序的ISR代码（如果引导加载程序是活动的）。如果在引导加载程序中不使用中断，则无条件调用是适用的。以上仅仅是原始概念，似乎很复杂，但这样的事情在之前就已经完成了。



      以下为原文

    Essentially, ISR remapping is not too difficult - even without IVT remapping support:

• Consider the IVT the "possession" of the bootloader.
  
• Define an area for the application's IVT - at some constant address.
  
• Make the bootloader "aware" of whether it is active or passive (e.g. using some variable at an absolute location - shared with the application).
  
• The bootloader's ISRs are "real ISRs" - providing the entry/exit code.
  
• The application's ISRs are formally simple functions void ISR(void) - though their address has to be stored in the application's "IVT".
  
• When an interrupt occurs, the bootloader's ISR has to check whether to call the application's ISR function (in case the bootloader is passive) or to execute the bootloader's ISR code (in case the bootloader is active).
  If an interrupt is not used in the bootloader, an unconditional call is applicable.
  
• Some more things are to be considered - the above is only the raw concept.
  

May seem to be complicated, but such things have been done before...

我希望如此！让我们在GLD文件上一步一步地尝试……引导加载程序GLD/**内存区域*/内存{数据（A）！XOR＝0x1000，长度＝0x8000重置：原点＝0x0，长度＝0x4IVT:原点＝0x4，长度＝0x1FC程序（XR）：原点＝0x200，长度＝0x21fc/*只减少了PROG大小*/ISRCONTRON: ORACE＝0x23 FC，长度＝0x4/*控制区域到ISR的跳转表*/.. }…0；γ-CODEL长度＝0x2200；γ-IVTXBASE＝0x4；γ-IsRealObjixBase= 0x23 FC；APP GLD/**内存区域*/内存{DATA（A）！XORE＝0x1000，长度＝0x8000重置：原点＝0x800，长度＝0x4/*改变位置*/IVT:原点＝0x2404，长度＝0x1fc/*改变位置*/程序（XR）：原点＝0x2600，长度＝0x2200／*改变位置和大小（仅用于测试）*/…}…关于*/yoCayl长度＝0x2200；/*更改大小（仅用于测试）*/y-iVtxBase= 0x2404；/*更改位置*/这个“ISRCORMIT”区域是否足够？使用这样的东西不会减少我的MCU寿命（在闪存中写入太多）？正常地编码（即，空x属性）（（α-BythTyp*（α-SaveSe*（AcCa，AcAcL）），NoAutoPSV））T1中断（空隙）？好的，但是如何在APP IVT中存储这些地址呢？像这样在Bootloader GLD中（我在论坛中找到一篇文章——抱歉作者，我忘了复制链接）：/***中断向量表***这个表已经从原来的内容修改到跳转到.ApdioTysIVT Goto表。用一个程序员来代替一个Bootloader的程序，它会像引导加载程序一样工作，导致相同的中断等待时间。*/IVT.I.IttBase:{Load（绝对（Apple，AppIVItBASE）+0x00）；溶质（γ-AppIVItBaseBase+0x00 c）；/*α-AddiSerSerR*/Lon（绝对（α-AppIVItBaseBASE）+0x010）；/*Ayth-StAccess错误*/……} & IVTor就像他的在一个应用程序GLD（也从论坛复制，再次对不起作者）：***关闭内存部分**JSReaveDeTrAP0= 0x0C02；JySimulaseReals= 0x0C06；JAdAdSerSRRoR＝0x0C0a；JyStActReals= 0x0C0e；……再次，如何做到这一点？在一个应用程序GLDL/**中断向量表*/jyIVT.JivtBase:{短（0x05）；/*Bootloader超时在秒*/短（0x00）；/*yaseReaveDeRAP0*/Lead（定义）（？绝对值（α-ReaveDeTrAP0）：绝对值（α-Debug中断）；短（0x04）；短（（定义的）绝对值（α-RealvEdTrAP0）：绝对（α-Debug中断）& gt；& gt；16）& 0x7f；短（0）；/*α振荡子失败* /短（定义（α，振荡器失效））绝对值（γ振荡子失败）：绝对（α，默认中断）；短（0x04）；短路（（定义为振荡振荡器）？绝对值（γ振荡子）：绝对（α，默认中断）& gt；& gt；16）& 0x7f；短（0）；…} & JT IVT在Bootloader GLD/***图中用于中断向量表*/Cuths{/**。本节定义了一个存在于用户空间中的中断重映射表。每一行代表**表中的条目。每个条目都包含一个“Goto OyDebug中断”或“GTO to SyEnter中断”**，这取决于在用户代码中是否定义了用于中断的中断处理程序。真正的IVT表**在每个中断向量条目中都有一个固定的跳到这个表中的一个条目。* /应用程序IVT.AppIVItBase: {短（绝对（重置））；短（0x04）；短（绝对（α-Read）& gt；& gt；16）& 0x7f）；短（0）；短（定义（α，保留，rTRAP0））绝对值（α-RealvEdTrAP0）：绝对值（α-Debug中断）；短（0x04）；短（定义）（绝对（α-RealvEdTrAP0）& gt；& gt；16）& 0x7f：（绝对（α-Debug中断）& gt；and 16；）；0x7f）；短（0）；短（定义（α，振荡，失效））绝对值（γ振荡子失败）：绝对（α，默认中断）；短（0x04）；短路（定义（振荡）？（绝对（So SurvivaRebug）& gt；& gt；16）& 0x7f：（绝对（α-Debug中断）& gt；and 16；）；0x7f）；短（0）；短（定义）（？绝对（α-AdxRelsRor）：绝对（α-Debug中断）；短（0x04）；短（定义）？（绝对（α-AddiSRESRR）& gt；& gt；16）& 0x7f：（绝对（α-Debug中断）& gt；and 16；）；0x7f）；短（0）；……DeFultTyValth.=；短（绝对（α-Debug中断））；短（0x04）；短（（绝对（α-Debug中断）& gt；and 16；）；0x7f）；短（0）；}我希望我没有写给许多虚拟的东西！谢谢！



      以下为原文

   
I hope so! Let´s try step-by-step...

Something like this on my GLD files?
BootLoader GLD
/*
** Memory Regions
*/
MEMORY
{
data (a!xr) : ORIGIN = 0x1000, LENGTH = 0x8000
reset : ORIGIN = 0x0, LENGTH = 0x4
ivt : ORIGIN = 0x4, LENGTH = 0x1FC
program (xr) : ORIGIN = 0x200, LENGTH = 0x21FC /* Only reduced the prog size */
isrcontrol : ORIGIN = 0x23FC, LENGTH = 0x4 /* Control area to isr´s jump table */
....
}
...
__CODE_BASE = 0x200;
__CODE_LENGTH = 0x2200;
__IVT_BASE = 0x4;
__ISRCONTROL_BASE = 0x23FC;

App GLD
/*
** Memory Regions
*/
MEMORY
{
data (a!xr) : ORIGIN = 0x1000, LENGTH = 0x8000
reset : ORIGIN = 0x2400, LENGTH = 0x4 /* Change location */
ivt : ORIGIN = 0x2404, LENGTH = 0x1FC /* Change location */
program (xr) : ORIGIN = 0x2600, LENGTH = 0x2200 /* Change location and size (for tests only)*/
...
}
...
__CODE_BASE = 0x2400; /* Change location */
__CODE_LENGTH = 0x2200; /* Change size (for tests only) */
__IVT_BASE = 0x2404; /* Change location */

This "isrcontrol" area is enough? Using something like this won´t reduce my MCU lifetime (too many writes in a flash memory)?

Coded normally (i.e. void __attribute__((__interrupt__(__save__(ACCAH,ACCAL)),no_auto_psv)) _T1Interrupt(void) )?

OK, but how to store this addresses in APP IVT? Like this in a bootloader GLD(I found it in an article here in forum - sorry authors, I forgot to copy the link):
/*
** Interrupt Vector Table
**
** This table has been modified from the original content to jump to the .application_ivt goto table.
** This is done so that when this linker file is used to program a device using a programmer instead
** of the bootloader, it will work just like the bootloader resulting in identical interrupt latency.
*/
.ivt __IVT_BASE :
{
LONG(ABSOLUTE(__APP_IVT_BASE) + 0x004); /* __ReservedTrap0 */
LONG(ABSOLUTE(__APP_IVT_BASE) + 0x008); /* __OscillatorFail */
LONG(ABSOLUTE(__APP_IVT_BASE) + 0x00C); /* __AddressError */
LONG(ABSOLUTE(__APP_IVT_BASE) + 0x010); /* __StackError */
.....
.....
} >ivt
Or like his in an APP GLD (also copied from the forum, again sorry authors):
*** Close the Memory section ***
J_ReservedTrap0 = 0x0C02;
J_OscillatorFail = 0x0C06;
J_AddressError = 0x0C0A;
J_StackError = 0x0C0E;
....
....

Again, how to do it?
In an APP GLD
/*
** Interrupt Vector Tables
*/
.j_ivt __JIVT_BASE :
{
SHORT(0x05); /* Bootloader timeout in sec */
SHORT(0x00);

/* __ReservedTrap0 */
SHORT(DEFINED(__ReservedTrap0) ? ABSOLUTE(__ReservedTrap0) :
ABSOLUTE(__DefaultInterrupt));
SHORT(0x04);
SHORT(((DEFINED(__ReservedTrap0) ? ABSOLUTE(__ReservedTrap0) :
ABSOLUTE(__DefaultInterrupt)) >> 16) & 0x7F);
SHORT(0);
/* __OscillatorFail */
SHORT(DEFINED(__OscillatorFail) ? ABSOLUTE(__OscillatorFail) :
ABSOLUTE(__DefaultInterrupt));
SHORT(0x04);
SHORT(((DEFINED(__OscillatorFail) ? ABSOLUTE(__OscillatorFail) :
ABSOLUTE(__DefaultInterrupt)) >> 16) & 0x7F);
SHORT(0);
...
...
} >j_ivt

In bootloader GLD
/*
** Section Map for Interrupt Vector Tables
*/
SECTIONS
{
/*
** This section defines a interrupt remap table that exists in the user space. Each line represents
** an entry in the table. Each entry contains either a "goto __DefaultInterrupt" or "goto __CertainInterrupt"
** depending on if the interrupt handler for __CertainInterrupt is defined in the user code. The real IVT table
** has a fixed jump at each of the interrupt vector entries to an entry in this table.
*/
.application_ivt __APP_IVT_BASE :
{
SHORT(ABSOLUTE(__reset)); SHORT(0x04); SHORT((ABSOLUTE(__reset) >> 16) & 0x7F); SHORT(0);
SHORT(DEFINED(__ReservedTrap0) ? ABSOLUTE(__ReservedTrap0) : ABSOLUTE(__DefaultInterrupt)); SHORT(0x04); SHORT(DEFINED(__ReservedTrap0) ? (ABSOLUTE(__ReservedTrap0) >> 16) & 0x7F : (ABSOLUTE(__DefaultInterrupt) >> 16) & 0x7F); SHORT(0);
SHORT(DEFINED(__OscillatorFail) ? ABSOLUTE(__OscillatorFail) : ABSOLUTE(__DefaultInterrupt)); SHORT(0x04); SHORT(DEFINED(__OscillatorFail) ? (ABSOLUTE(__OscillatorFail) >> 16) & 0x7F : (ABSOLUTE(__DefaultInterrupt) >> 16) & 0x7F); SHORT(0);
SHORT(DEFINED(__AddressError) ? ABSOLUTE(__AddressError) : ABSOLUTE(__DefaultInterrupt)); SHORT(0x04); SHORT(DEFINED(__AddressError) ? (ABSOLUTE(__AddressError) >> 16) & 0x7F : (ABSOLUTE(__DefaultInterrupt) >> 16) & 0x7F); SHORT(0);
....
....
DEFAULT_VECTOR = .;
SHORT(ABSOLUTE(__DefaultInterrupt)); SHORT(0x04); SHORT((ABSOLUTE(__DefaultInterrupt) >> 16) & 0x7F); SHORT(0);
}
 
I hope I didn´t write to many dummy things!
Thanks!

我更喜欢“APP GLD”风格。虽然这些事情可以在很多方面实现，但是“Bootloader意识”：这是一个RAM变量，所以编程循环考虑不适用。将它设置为“Bootloader”，在重置后，在输入应用程序代码时返回“应用程序”，当返回到Bootl时返回“Bootloader”。来自应用程序的OADER。基本上就是这样。



      以下为原文

    I'd prefer the "APP GLD" style. Although these things can be achieved in many ways.
Re the "bootloader awareness": this is a RAM variable, so programming cycle considerations do not apply.
Set it to "bootloader" following reset, to "application" upon entering the application code, back to "bootloader" when/if returning to the bootloader from the application. That's it basically. 

是的，我用RAM找到了这个“意识”，它工作得很好！我可以将我的Bootloader模糊化，在RAM中写入一个值，更改为App，读取那个值，正确地重写它，返回到Bootloader并再次读取它，但是我无法实现如何使用它来重定向ISR S到正确的位置。代码中的值如何改变GLD中的定义？



      以下为原文

   
Yes, I figured out how to this "awareness" using RAM and it is working fine!
I can inicialize my bootloader, write a value in RAM, change to app, read that value correcly overwrite it, return to bootloader and read it again.
 
But I couln´t realize how to use it to redirect the ISR´s to the right place!
How could a value in code change a define in the GLD?

意识需要ISR代码的“共享”中断来检查变量：当它是“Bootloader”时，然后引导引导程序的代码被执行。当它指示“应用”时，应用程序的功能（地址存储在应用程序的“虚拟IVT”）被称为“正常函数调用”。中断只使用BA。应用程序不需要检查变量——只需调用应用程序的服务功能。对于任何ISR，ReFiE都在引导加载程序的ISR代码中。



      以下为原文

    The awareness requires the ISR code of "shared" interrupts to check the variable: when it is "bootloader", then the bootloader's code is executed. When it indicates "application" then the application's function (address is stored in the app's "virtual IVT") is called ("normal function call).  Interrupts used only ba the application do not need to check the variable - just call the application's service function.
RETFIE for any ISR is in the bootloader's ISR code.

谢谢大家！你是对的。共享ISR的BETNEN应用程序和Bootloader是一个很难的问题。我可以在ISP（主应用程序和Bootloader）上闪烁一个LED，但是代码变得凌乱。现在我正在尝试“计划B”——在我的DSC上双倍闪存，把所有的警告信息带到我的PC应用程序中，并且真正地“刷新”DSC中的所有数据，而不受用户干扰。



      以下为原文

    Thanks guys!
You were right. Sharing ISR´s betwenn app and bootloader is a tough question.
I could blink a LED using ISR´s on both (main app and bootloader), but the code became messy!
Now I am trying the "Plan B" - double the flash memory on my DSC, bring all the warning messages to my PC app and really "reflash" the memory after all data in the DSC and without user interference.
 

正如你迟早会发现的：“计划B”甚至更复杂。将一个基本验证的引导加载程序和一些单独的应用程序代码（不需要处理Flash编程问题）分离是一件好事。



      以下为原文

    As you will find out sooner or later: "plan B" is even complexer. The separation into a - basically validated - boot loader and some separate application code (that does not have to fiddle with flash programming issues) is a good thing.

嗨，Korbes，我刚刚检查了你的DSPIC33 EP256MC204的数据表。它有标准的Flash组织。一些其他的DSPIC33 EP有所谓的“LIVUEPDEND”功能，这对你的使用可能是有用的。基本上有2个闪存面板（例如2×256kb），它们可以被用作一个闪存区域。或者作为2个独立的区域。概念是，当Bootloader编程另一个面板时，您的应用程序可以全速运行。一旦新的应用程序图像被下载和验证，您只需要切换面板来运行新映像。如果有任何故障，您可以重新启动BootLoad。具有生存能力



      以下为原文

    Hi Korbes,
I just checked the datasheet of your dsPIC33EP256MC204.
It has standard Flash organization.
Some other dsPIC33EP have so called "Liveupdate" capability which might be useful for your usage.
Bascially there are 2 panels of flash (e.g. 2 x 256KB) which can either be used as a single flash area or as 2 separate areas. The concept is that your application can run at full speed while the bootloader program the other panel.
Once the new application image is downloaded and verified, you just need to switch the panel to run the new image.
If anything fails you can restart bootloading.
Regards
e.g. some dsPIC33EPxxxGSyyy have liveupdate capability