我在自己编写USB IAP烧录功能的过程中，遇到了关于APP-->Bootloader跳转的问题，详细内容如下描述，希望大家能提供一些解决方案与技术支持，谢谢
 
平台：
1.         使用芯片：STM32F217.
2.         硬件平台：公司内部设计的Demo仿真板.
 
现今状况：
1.         Bootloader代码放在 0x08000000 ~ 0x08008000 地址区；APP代码放在0x08008000 ~ 0x080FFFFF区域；
2.         Bootloader与APP两个代码中都加入了USB_DEVICE_LIB和Virtual COM Port功能，且单独运行Bootloader，能正常通过VCP烧录APP代码；单独运行APP，能正常通过VCP烧录Bootloader代码。
3.         当前采用的代码跳转方式
a)         Bootloader跳转至APP的方式：
参考官方SCI-IAP例程（AN2557），Bootloader上电时检测是否在烧录模式.
                         i.              若否，则JumpAddress = *(__IO uint32_t*) (0x08008000 + 4); 直接将PC指针跳转到APP代码入口地址；
                       ii.              若是，则进入SCI & VCP烧录模式，对APP代码进行烧录，烧录完毕后驱使芯片SoftwareRest.
b)        APP跳转至Bootloader的方式：
在APP代码中，当检测到需要烧录APP代码时，采用SoftwareRest的方式，跳转至Bootloader程序，进入SCI & VCP烧录模式。
 
已实现功能：
1.         完整实现普通SCI串口烧录功能.
a)         APP中通过SCI串口烧录Bootloader.
b)        APP检测到需烧录APP代码时，通过SoftwareRest，进入Bootloader代码的烧录模式，对APP代码进行烧录。
 
遇到问题：
1.         不能实现通过Virtual COM Port烧录APP代码的功能。
a)         原因分析：
                         i.              在烧录APP代码时，需要通过SoftwareRest的方式进入Bootloader代码的烧录模式。但是，当芯片Reset后，USB的DP脚的3.3V上拉会消失，导致PC认为USB设备断开，当Bootloader代码对USB寄存器进行重新初始化后，DP脚的3.3V上拉重现，PC认为USB设备连接，这就相当于对USB设备进行了一次热插拔。
                       ii.              同时，由于此时上位机正在占用着VCP的端口号，所以，当在USB设备被PC重新识别时，会由于端口号被占用而导致识别失败，从而导致上位机不能通过VCP发送任何数据，使得在Bootloader烧录模式下不能继续对APP代码进行烧录。
b)        临时解决方式：
在芯片从APP代码通过SoftwareReset跳转至Bootloader代码后，退出上位机，重新热插拔USB设备，则PC能重新正确识别Virtual COM Port，此时再打开上位机，即可通过VCP 烧录APP的代码。
 
需求方案：
       虽然通过“退出上位机”à“热插拔USB”à“重新运行上位机”这样的操作后，能够实现通过VCP烧录APP代码的功能。但是，此方式并不能满足项目实际应用需求。项目实际应用中，烧录过程需要能连贯进行。
       所以，我想询问：
a)         是否可以通过非SoftwareReset的方式，实现从APP代码到Bootloader代码的跳转。

帖子显示不完全，下面继续补充一下：
需求方案：
        虽然通过“退出上位机”“热插拔USB”“重新运行上位机”这样的操作后，能够实现通过VCP烧录APP代码的功能。但是，此方式并不能满足项目实际应用需求。项目实际应用中，烧录过程需要能连贯进行。
        所以，我想询问：
a)        是否可以通过非SoftwareReset的方式，实现从APP代码到Bootloader代码的跳转。
b)        同时，在跳转过程中，保持USB外设不需要被PC重新识别，实现跳转到Bootloader后不需热插拔USB，Virtual COM Port 也能正常运行，从而完成对APP的烧录.
希望您们能抽空思考此问题，同时给予一些实现方案和技术指导。谢谢~

你这个问题解决的办法最好通过PC机软件来结局，比如当检测到这个端口无效的时候，自己断开，然后等待有效的时候，再重新执行USB串口的连接。如果跳转你可以使用类似从bootloader跳转到APP的指令来实现。但是，这样就会在每次跳转以后重新初始化USB，所以这个还是不可取的。如果可以使用MCU本身的串口来做，这个就可以避免。

回复第 3 楼 安于2011-06-03 07:29:58发表:
你这个问题解决的办法最好通过PC机软件来结局，比如当检测到这个端口无效的时候，自己断开，然后等待有效的时候，再重新执行USB串口的连接。如果跳转你可以使用类似从bootloader跳转到APP的指令来实现。但是，这样就会在每次跳转以后重新初始化USB，所以这个还是不可取的。如果可以使用MCU本身的串口来做，这个就可以避免。 

    谢谢你的回答, 由于上位机不能修改,所以我想还是从MCU入手. 现在我有两个猜想:
    1.   如果使用类似Bootloader跳转到APP的指令来实现, 在从APP跳转到Bootloader前,不对USB寄存器进行复位, 跳到Bootloader后，也不重新初始化USB寄存器. 这样的话是否可以使USB外设保持工作,使PC不重新枚举USB设备呢?
    2.  依旧使用SystemReset的方式实现从APP跳转到Bootloader, 但是人为地在DP管脚上增加1.5Kohm 3.3V上拉, 以此欺骗PC, 使PC不重新识别USB设备, 这样跳到Bootloader后继续使用VCP.
    上述第一种方案已作测试, 但是JumptoBootloader后,能运行Bootloader的代码,且能响应中断, 可以在JTAG调试下单步运行, 但只要点击全速运行,则会跑到HardfaultHandler.
    第二种方案仍未尝试.
    请问斑竹对上述两种方案的可行性有什么看法呢? 谢谢~ ^_^

测试发现,利用DP口外加上拉电阻的方式 并不能 欺骗PC, 在Jumptobootloader后,PC依然认为USB DEVICE disconnect了...
同时,利用PC地址跳转的方式,可以跳转到Bootloader,可以进入TIM2中断,也可以进行单步运行.在TIM2中断中增加unsigned long 变量udwCnt, 每进入一次TIM2中断加1, 单步运行时,该值可以一直加到1500,而且可以继续单步运行. 但是,如果按全速, udwCnt 只能加到2, 代码就进入HardfaultHandler()了... 这个可能会是什么问题呢...
"可以单步运行,但是不可以全速运行.."

請問樓主解決了嗎? 我目前遇到跟你一樣的問題，只要從APP跳轉至IAP，USB就會列舉失敗，使得無法在IAP區進行USB通訊，也試過了再IAP區不重新初始化USB，可以傳資料到PC端，但是IAP區的USB收資料中斷卻無效了，真是頭大阿!!