您好,我已经为我的基于DSPIC33的项目(高集成产品)实现了一个基于CAN的BooTooLoad。该项目使用在应用程序注释中概述的方法,该映射将IVT映射到主应用程序中的跳转表(Bootloader不使用任何中断)。我很高兴这样做的预期,并避免硬编码到Bootloader太多的东西,虽然我不得不生活在轻微的增加,由于额外的跳转延迟。我的查询涉及不可屏蔽中断向量(例如堆栈,DMAC,振荡器等)。在主应用程序中,我为这些定义了处理程序。但是,在下载应用程序之前,不存在任何处理程序,因此异常将导致执行传递到不存在的跳转表中。为了减轻这个问题,我最初确保当下载引导程序HEX时,跳表被零填充,这将导致任何非屏蔽中断的设备复位。但是,这在某些时候不支持引导加载程序的部分/失败的下载(例如,页面擦除后的
电源故障将FFS转换为NOPS,因此我们可能会在闪存的剩余部分中执行随机数据)。推荐什么方法来处理非屏蔽中断。理想情况下,我认为在任何异常情况下,我都会在Bootloader中执行设备重置,但是在主应用程序中运行指定的处理程序。我考虑了一些选项:-在公共闪存页面中的固定地址中查找异常处理程序,以加载引导加载程序,但是可以在下载过程中被反射(擦除/写入过程中出现的问题的可能性很小)-在引导加载程序中找到非可屏蔽中断的异常处理程序,因此它们总是存在。这意味着他们不能改变未来的感激之情。
以上来自于百度翻译
以下为原文
Hello,
I have implemented a CAN-based bootloader for my dsPIC33E based project (high integrity product). The project uses the approach outlined in the applica
tion notes which maps the IVT to a jump table in the main application (bootloader does not use any interrupts). I am happy that this working as expected and avoids hard-coding too many things into the bootloader although I have to live with the slight increase in latency due to the extra jump.
My query relates to the non-maskable interrupt vectors (e.g. stack, DMAC, oscillator etc.). I have handlers defined for these in the main application. However, prior to downloading the application, no handler exists so the exception would cause execution to pass to the jump table which doesn't exist! To mitigate this problem initially I have ensured that the jump table is filled with zeros when the bootloader hex is downloaded, which should result in a device reset for any of the non-maskable interrupts. However, this doesn't protect for partial/failed downloads by the bootloader at some point later (e.g. power failure after page erase gives FFs which translate to NOPs so we may end up executing random data in the remainder of flash).
What is the recommended way to handle the non-maskable interrupts? Ideally, I think I would perform a device reset whilst in bootloader for any of these exceptions, but run the designated handler when in the main application.
Some options I considered:
- locate exception handlers at a fixed address in a common flash page to be loaded with the bootloader but could be reflashed during download (small chance of problems during erase/write)
- locate exception handlers for the non-maskable interrupts in the bootloader, so they are always present. This means they can't be changed in the future
Thanks
T