引导程序和应用程序重置向量的问题

您好，我有一个PIC16F1829，用XC8V2.0编译器编写C。我使用MCC生成的Bootloader，它遵循8位Bootloader通信协议（http://www. McCyc.com /PROVO/8位Bootloader）。我自己的Bootloader主机程序在UART上闪动Bootloader。我现在做的是：*将所有从0x0擦除到Bootloader固件（0x1BA0）*将Bootloader复位向量写入0x0（4个指令）*在Bootloader固件（0x1B9C）之前写应用程序复位向量。应用程序从0x4到0x1b9c.*在每次写入之后计算校验和。*写EEPROM和CHECK.*Read设备。在MPLAIDE内部，我为我的应用程序设置以下限制：ROM范围：默认，-1B9C-1FFFand用于引导加载程序：ROM范围：1BA0- FFFAll似乎工作得很好。应用程序按预期启动和工作，我也可以重新启动到Bootloader和Flash。应用程序的程序内存闪存，ICD 3与引导加载的应用程序几乎相同。唯一不同的是，在ADDR 0x0上，引导装载器复位向量被定位，应用程序复位向量在0x1B9C上。正如预期的那样，配置位对于引导加载程序和应用固件是相同的。现在问题是如果我使用引导加载程序：-& gt；应用程序u。ART发送或接收错误的字节，但只针对特定的命令。如果应用程序在程序中闪烁，这不会发生。如果使用Bootloader并将应用程序重置向量放置在0x0（覆盖Bootloader复位向量），问题就消失了。为什么？？？？我首先想到的问题是，引导加载程序固件在启动时设置了一些PIN /配置，这不是我的应用程序处理的，但是我的引导加载程序的启动代码开始于：任何时钟/GPIO/USAT配置都会发生（如果需要引导程序）。如果应用程序启动Bootloader，RXCHECK（）检查0x78中的持久值。有人知道问题是什么，或者我的下一步可能是什么？
                    
                    
               
                                                                                      以下为原文

                                                                            Hello,

I have a PIC16F1829 and write in C with the XC8 v2.0 compiler.

I use the bootloader generated by mcc which follows the 8-bit bootloader communication protocol (http://www.microchip.com/promo/8-bit-bootloader).

And I modified the bootloader to perform the following memory structure:

I also write my own bootloader host program which flashes the bootloader over UART.

What I currently do:
* Erase all from 0x0 to bootloader firmware (0x1BA0)
* Write bootloader reset vector back to 0x0 (4 instructions)
* Write application reset vector just before the bootloader firmware (0x1B9C)
* Write the rest of the application from 0x4 to 0x1B9C.
* Calculate checksum after every write.
* Write EEPROM and check.
* Restart device.

Inside MPLAB IDE I set for my application project the following restriction:
ROM ranges: default,-1B9C-1FFF

And for the Bootloader:
ROM ranges: 1BA0- FFF

All seems to work great. The application starts and works as expected and I can also restart into the bootloader and flash again.
The program memory of the application flashed with an ICD 3 is nearly identical to the bootloaded application. The only different is that on addr 0x0 the bootloader reset vector is located and the application reset vector is at 0x1B9C. Just as expected.
The configuration bits are the same for the bootloader and application firmware.

Now the problem what happens if I use the bootloader:
-> The applications UART sends or receives wrong bytes but only for specific commands

This does not happen if the application is flashed over the programmer.
And if I use the bootloader and place the application reset vector at 0x0 (overwrite bootloaders reset vector) the problem is gone. WHY???

I first thought the problem is, that the bootloader firmware sets some PIN/configurations at startup which is not handled by my application, but my startup code of the bootloader begins with:

void bootloder_init(void) {
if (!bootloader_required()) {
STKPTR = 0x1F; // Reset stack.
asm("movlp " str(APPLICATION_RESET_VECTOR >> 8));
asm("goto " str(APPLICATION_RESET_VECTOR & 0x7FF));
}
}

bool bootloader_required(void) {
if (bootloader_indicator_check()) {
bootloader_indicator_clear();
return true;
}
// ******************************************************************
// Check the reset vector for code to initiate bootloader
// ******************************************************************
// This section reads the application start
// vector to see if the location is blank
// (0x3FFF) or not. If blank, it runs the
// bootloader. Otherwise, it assumes the
// application is loaded and instead runs the
// application.
EEADRL = APPLICATION_RESET_VECTOR & 0xFF;
EEADRH = (APPLICATION_RESET_VECTOR & 0xFF00UL) >> 8;
EECON1 = 0x80;
EECON1bits.RD = 1;
NOP();
NOP();
if ((EEDATH == 0x3F) && (EEDATL == 0xFF)) {
return(true);
}
return(false);
}


Any CLOCK/GPIO/USART configuration happens afterward (if the bootloader is required).

The bootloader_indicator_check() checks a persistent value at 0x73 if the application started the bootloader.

Does anyone have an idea what the problem could be or what my next step could be?