Microchip
直播中

任迎新

7年用户 174经验值
私信 关注
[问答]

dsPIC33E Bootloader怎么查询

您好,我已经为我的基于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 application 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

回帖(2)

王璨

2018-11-1 17:17:49
(仅适用于无法禁用/屏蔽的中断)实现“有效的应用程序可用”。如果没有有效的应用程序,请不要跳转。这将需要在引导加载程序本身中实现一些服务。这给非屏蔽的“事件”延迟添加了一点,但这并不重要,因为这些事件不应该在“正常”条件下发生。

以上来自于百度翻译


      以下为原文

    (Only applicable for the interrupts that cannot be disabled/masked)

  • Implement a "valid application available" check
  • Don't jump if you don't have a valid application. Which will require some service implemented in the boot loader itself.
This adds a bit to the non-maskable "events" latency, but this doesn't really matter as these events shouldn't happen under "normal" conditions.
举报

宋晓媛

2018-11-1 17:27:04
编写程序存储器是一个两步过程:擦除一个完整的程序存储器页,然后用写锁存器写入擦除页的程序存储器。写入锁存器(通常在地址0xFA000)临时存储指令。然后,这些指令通过写入密钥序列并将NVMCon设置为正确的值而写入程序存储器空间。要写入的地址由TBLWTH/TBLWTL指令定义。Bluestacks TextNow Photomath

以上来自于百度翻译


      以下为原文

    Writing to program memory is a two-step process: Erase a full page of program memory and then write the program memory of the erased page using the write latches. The write latches (typically at address 0xFA0000) temporary store instructions. These instructions are then written to the program memory space by writing a key sequence and setting NVMCON to the correct value. The addresses to write are defined by TBLWTH/TBLWTL instructions. Bluestacks TextNow Photomath
举报

更多回帖

发帖
×
20
完善资料,
赚取积分