引导加载程序出现问题，应用程序无法执行其启动代码

嗨，我写了自己的Bootloader为DSPIC33 EV系列。我用一个小应用程序测试了几个LED，并有其他功能散布在整个程序存储器中，但是我尝试闪亮一个更大的固件，固件在应用程序的启动代码中被卡住，检查RCON显示IopuWR位是在STARTU中的某个点设置的。Bootloader的体系结构是这样的：Bootloader位于前8页（我计划使用CODEGARID，只要我能在扇区内获得功能……这是另一个故事。）设备重置向量点在0x400，第1页，其中引导加载程序超过它自己的启动代码。易失性const int属性（（地址（0x200））RES（256）＝{ 0，}；是这样的，编译器认为第0页的第0页实际上被占用，没有代码被放置在0x200和0x中。应用重置向量在0x2000。设备引导。EXECUTE Bootloader启动代码，进入Bootloader MIN。在主程序中，如果一个特定的PIN被短路到地上，在这种情况下它将进入Bootloader，如果不是，那么它检查在0x2000是否有一个有效的操作码（如果它与0xFFFFFF不同）。如果没有有效的操作码，它将开始执行引导加载程序，否则将在0x2000跳到0x2000，然后启动应用程序启动代码。我确信这一点，因为在应用程序中，我做了同样的事情来保留StaseDeavyListconst int属性（（地址（0x200））RES（3840）＝{ 0，}；并且编译后的HEX确实有一个Goto 0x2000作为复位向量，在0x200和0x1FFFF过程中没有代码存在，当下载应用程序时，WH。EnBootloader写到第0页，第0行，它将用一个NOP替换Goto 0x400跟随器的App Read vector。我用两个简单的固件测试Bootloader，它将以不同的模式闪烁LED，它工作了。然后我尝试使用一个更复杂的应用程序（一个可以运行的应用程序）。LLY使用在这个板上，但是MCU不能通过应用程序启动代码：直到它退出引导加载程序才能正常运行，然后它在第二个启动代码中停留在某个地方，重新启动并且循环继续下去。我从设备上上传了代码，并验证了它实际上是引导加载程序代码和应用程序代码的结合。我将十六进制与另外两个代码进行了比较，并与预期的一样：-将重置向量引导到引导程序-从应用程序-引导程序代码从0x400到0x1FFF的中断向量。-从0x2000到结束的应用程序代码。然后我打开了HEX作为X（PrimBudieHEX）中的一个新项目并点击调试器。在某个点重置，检查RCON之前和之后显示IOUWWR位是设置非法代码检测或非法地址模式，或者作为地址指针使用的未初始化W寄存器导致RESEti然后进行此测试：我编辑了HEX文件，使启动向量为0x2。000（绕过Bootloader），应用程序启动得很好。我真的不知道如何进行。



      以下为原文

    Hi,
i wrote my own bootloader for dsPIC33EV series. I tested with a small application that blinks a couple of LEDs and has other functions scattered across whole program memory, but then i tried flashing a bigger firmware and firmware gets stuck during application's startup code, Checking RCON shows that IOPUWR bit is set at some point during startup.

Deeper explanation:
The bootloader architecture is such: Bootloader is located in the first 8 pages (i plan to use codeguard as soon as i can get functions to work inside sectors... that's another story.)
device reset vector points at 0x400, page 1, where the bootloader excecute its own startup code.
volatile const int __attribute((address(0x200))) res[256] = {0,};
is present so the compiler thinks second half of page 0 is actually occupied and no code is placed from 0x200 and 0x3FF.

Application reset vector is at 0x2000.

Device boots. Excecutes bootloader startup code, enters bootloader main.
inside main it checks if a particular pin is shorted to ground, in that case it will enter bootloader, if not then it checks if there is a valid opcode at 0x2000 (if it's different than 0xFFFFFF). If no valid opcode is there it will start doing bootloader stuff, otherwise it will jump to 0x2000

At 0x2000 then starts the application startup code. I am sure of this because in the application i did the same thing to reserve space
volatile const int __attribute((address(0x200))) res[3840] = {0,};
and the compiled hex does have a goto 0x2000 as reset vector, no code is present between 0x200 and 0x1FFF

Of course, when downloading an application, when bootloader writes to Page 0, Row 0 it will substitute the app reset vector with GOTO 0x400 follower by a NOP.

I tested the bootloader with a couple of simple firmwares that would blink leds in different patterns, it worked.
I then tried using a more complex application (the one that would be actually used in this board) but the MCU can't get past the application startup code:
it goes fine until it exits the bootloader, then it gets stuck somewhere during the second startup code, reboots and the cycle goes on forever.

What i did to veryfy this: along using led patterns to identify where it got stuck, i uploaded the code from the device, and verified that it is effectively the union of the bootloader code and the application code.

I diff'd the hex with the other two and it is as expected:
- Reset vector to bootloader
- Interrupt vectors from application
- Bootloader code from 0x400 to 0x1FFF
- Application code from 0x2000 till the end.

I then opened the hex as a new project in X (prebuild hex) and hit the debugger.
this way I confirmed that the bootloader goes through and it excecutes some of the startup code. At some point the part resets, checking RCON before and after shows that IOPUWR bit is set

An Illegal Opcode detection or an Illegal Address mode, or Uninitialized W register used as an Address Pointer caused a Reset

I then made this test: I edited the hex file so that the startup vector would be 0x2000 (bypass the bootloader)
the application starts up fine.

i really don't know how to proceed