在利用MCC开发Bootloader和Application时需要注意一些关键问题。
Bootloader部分
1）Bootloader最大空间-Bootloader能分配的最大空间由目标Application和Flash的大小决定。在Bootloader区还应提供额外的备用闪存大小，以允许在项目的整个生命周期内增加Bootloader的大小。如果Bootloader的大小需要增加，它将影响所有现有的Application项目。所以在开发初期，一定要留充足的Flash空间大小，避免后续空间不足导致更改的内容过多。
2）应用程序确认方式-验证Application的方法是什么？ MCC生成的示例代码将检查代码的第一个地址是否有效。虽然这是有效的，但它的覆盖范围相对较低。开发者可能想要实现CRC检查例程。 HEXMATE提供了不同的工具来帮助计算十六进制文件中数据的校验和。（关于如何验证后续会单独开篇介绍）
3）中断选择-Bootloader开发者还需要使Application端的所有开发人员都同意将转发到特定处理程序和默认处理程序的中断列表。
4)配置字-Bootloader开发者需要确保Application的所有开发人员都进行相同的配置。在使用Bootloader下载代码之前，请通过在Application项目上使用MCC重新验证Bootloader与Application之间的配置位是否匹配，这一点非常重要。
5）Boot区选项-Bootlaoder开发者需要为任何选项（如引导选项或指示器选项）创建最终代码。此外，如果设备的任何外设均已通过其重置设置进行了修改，则需要对相应的Application进行修改，因为他们可能需要在配置其外设时解决这些差异。
Application部分
在理想的情况下，可以在不考虑Bootloader如何工作的情况下完成Application的开发，并且对于大多数问题，可以独立地开发两者。但是，由于它们共存于同一芯片上，并且Bootloader是在Application之前设置的，因此两者之间存在依赖性。无法避免交互的关键区域是共享外设，内存映射，中断和其他区域的配置。
1）共享资源-共享资源的配置是需要解决的主要问题之一。例如，考虑如果Bootloader和Application都使用UART，但它们以不同的方式使用UART，会发生什么情况。在Application开发期间，由于Application固件不使用Bootloader，它们始终会从复位状态配置UART，因此，它们仅需根据初始系统复位值来修改UART寄存器。但是，如果Bootloader在运行时且在跳转到Application代码之前配置UART，则UART将不再具有与没有Bootloader时相同的初始值，并且如果不解决这些差异，则Application将使用UART可能会在此时失败。因此，对于共享资源，Application代码需要知道Bootloader如何使用外设以及Bootloader使用的设置和这些设置对Application使用的影响。
2）中断-虽然Bootloader和Application之间的中断不是“共享的”，但由于Application中断向量确实位于Bootloader的闪存地址空间中，因此应用程序需要与Bootloader合作，以使所有中断都使用正确的方式跳转至Application方法。
3）配置位-Bootloader和Application之间的配置位必须相同是非常重要的。Application配置位与Bootloader的配置位匹配非常重要，以至于当MCC提取Bootloader的配置时，它会验证它们是否相同，如果不一致，则MCC将显示差异。原因很简单，配置位仅在运行Bootloader固件之前在设备复位时读取。这些配置位中的部分将控制时钟和其他设备特性。如果这些与Application设置不匹配，则该Application需要一个特定的时钟；如果Bootloader具有不同的设置，则Application代码将失败。