STM32 USB DFU升级中中断冲突的解决方法

"STM32-USB-DFU升级过程中遇到中断冲突的解决策略" 在STM32微控制器的USB DFU( Device Firmware Upgrade)升级应用中，常常会遇到一个问题：Bootloader和应用程序（APP）都可能使用相同的USB中断。由于Bootloader和APP各自拥有独立的USB功能，例如Bootloader用于固件更新，而APP用于正常运行时的数据交换或设备功能，当这两个部分共享相同的中断服务函数时，可能会导致系统混乱。本文将探讨如何解决这种中断冲突。 首先，ST官方库函数V3.5提供了对STM32 USB功能的支持。在实现DFU升级的APP程序时，通常会在`main`函数的开始设置中断向量表地址，例如： ```c SCB->VTOR = FLASH_BASE | 0X30000; ``` 这使得中断向量表指向APP的指定位置，避免与Bootloader的中断服务冲突。如果APP中并未使用与Bootloader相同的中断服务，那么程序将正常运行。但一旦涉及到共同的中断服务，问题就出现了。 当APP和Bootloader都使用USB中断，如插入或移除USB设备的中断，如果未正确处理，可能导致设备无法被主机识别。例如，Bootloader的中断服务函数可能处理的是DFU模式的USB枚举，而APP中则是读卡器模式的USB枚举。当APP运行时，如果USB插入，由于中断向量表仍指向Bootloader的USB服务函数，设备将以Bootloader的枚举参数响应主机，从而引发主机无法识别的错误。 要解决这个问题，我们需要理解STM32程序执行的流程。在APP启动后，如果发生USB中断，程序会根据中断向量表找到服务函数。在Bootloader的中断向量表中，USB中断服务指向Bootloader的代码，而不是APP的代码。因此，当APP尝试处理USB事件时，实际上执行了Bootloader的中断服务，导致枚举错误。 为了解决这个问题，我们可以采取以下策略： 1. **分离中断服务**：为Bootloader和APP创建不同的中断服务函数，确保每个函数只处理相应的USB操作。 2. **动态修改中断向量表**：在APP启动后，根据需要动态更改中断向量表，使USB中断指向APP的中断服务函数。这可以通过在APP的初始化阶段重新设置`SCB->VTOR`来实现。 3. **条件编译**：利用预处理器指令，根据当前程序状态（Bootloader或APP）选择正确的中断服务函数进行编译。 4. **中断处理前检查状态**：在中断服务函数开始时检查系统状态，确保执行适当的处理逻辑。 在USB读卡器程序中，也可以尝试类似的解决办法。例如，通过在`main`函数中添加设置中断向量表的语句，并确保在USB事件发生时调用正确的服务函数。同时，仔细检查USB描述符文件（如`usb_desc.c`），确保设备描述符匹配当前的操作模式。 处理STM32 USB DFU升级中的中断冲突，关键在于区分Bootloader和APP的中断服务，确保中断向量表始终指向正确的服务函数。通过以上方法，可以实现Bootloader和APP在使用相同中断时的无缝切换，保证USB功能的正常运行。