0
我正在为使用相对复杂的通信接口的ARM Cortex-M3编写启动加载程序;这与实际应用程序使用的相同。该应用程序使用Keil的RTX作为其内核，通信栈依赖于它。当然使用GCC。Keil RTX启动时的控制
引导加载程序执行以下基本步骤：
- 在启动时，一个有效的应用图片检查;如果没有可用的，则进入升级模式;
- 它检查按钮按钮作为进入升级模式的请求;如果发现，它进入升级模式。
- 找到一个有效的图像，并没有升级请求，它“启动”应用程序。
这是相当简化的，但它充分描述了我们的目的情况。
令人惊讶的证明困难的最后一个问题是启动应用程序。这个想法是禁用中断，设置向量表，堆栈指针，并跳转到新向量表中的应用程序的重置向量。所有这些工作只是桃色，除了不久之后，我得到一个硬性故障。
通过实验，如果我在一个简单的引导程序（不使用RTX或当然，通信堆栈）中执行此操作，那么引导到应用程序工作正常。所以看来RTX是个问题。
事情是，真正的引导程序在进入升级模式之前不需要RTX。所以明显的做法是在我们确定需要之前不启动RTX;然而，它似乎被入侵到了启动代码中，所以当我进入bootloader代码时，已经太晚了;的确，bootloader的main（）函数已经是一个线程了！
最好的方法似乎是不开始RTX（太糟糕了，我没有使用FreeRTOS！），直到我需要它;然而，这似乎需要一些黑客攻击。另一种方法是以某种方式禁用所有中断和异常，但由于某种原因，我还没有成功。有没有人有这两种方法的例子？
因此，引导程序和应用程序都是基于RTX的？如果是这样，最好的选择可能是完全改变计划 - 将所有内容链接到一个程序中，运行初始检查作为启动任务，然后启动“升级”或“应用程序”任务为适当。通过不重复单独的“引导加载程序”和“应用程序”映像之间的“相对复杂的”通信代码，这也可以节省您的闪存空间。 – Notlikethat
似乎需要从RAM或其他程序运行，并覆盖引导加载程序（因为它是正在上传的应用程序的一部分！）;恐怕，这会使系统太过混乱。但有趣的想法。很明显，当我说“相对复杂”时，我误导了你;虽然它很复杂，但并不是很大 - 我的引导程序大约是20 KB，我的应用程序是80 KB，并且该设备有1 MB！ – Bob