ARM Cortex M3引导加载程序,用户代码位于正常0地址?

ARM Cortex M3引导加载程序,用户代码位于正常0地址?,arm,bootloader,cortex-m3,Arm,Bootloader,Cortex M3,我一直在研究ARMM3引导加载程序,大多数看起来都是使用低内存中的引导加载程序代码和高内存中的用户代码。这要求用户应用程序在与引导加载程序一起使用时以不同的方式链接。这是位于0x00000000的引导加载程序代码上方的某个地址。我认为这是一个不便 我想知道是否有可能有一个位于高内存中的引导加载程序,但仍然允许用户应用程序正常链接,因此它在低内存中从0x00000000开始 我以前使用过PIC引导加载程序,它的重置和堆栈代码为0x0000,类似于ARM M3的NVIC表 他们的方式,这已经形成了我

我一直在研究ARMM3引导加载程序,大多数看起来都是使用低内存中的引导加载程序代码和高内存中的用户代码。这要求用户应用程序在与引导加载程序一起使用时以不同的方式链接。这是位于0x00000000的引导加载程序代码上方的某个地址。我认为这是一个不便

我想知道是否有可能有一个位于高内存中的引导加载程序,但仍然允许用户应用程序正常链接,因此它在低内存中从0x00000000开始

我以前使用过PIC引导加载程序,它的重置和堆栈代码为0x0000,类似于ARM M3的NVIC表

他们的方式,这已经形成了我的图片是,引导程序位于顶部1k的闪存。将0x0000处的向量和SP代码重置为引导加载程序代码的起始地址。因此,引导加载程序在重置后启动

现在,当引导加载程序下载用户代码时,它会将其放入链接器认为应该去的低内存中,唯一的例外是它不允许覆盖其自身的重置和位于0x0000的SP向量。取而代之的是,它“捕获”这些数据并将它们存储在高内存中的闪存中

当引导加载程序准备好让用户代码启动时,它将检索下载期间存储的初始重置和SP向量,并使用这些向量启动用户代码

在下一次重置时,引导加载程序将启动,它可以检查是否应该等待新的用户程序,或者使用它存储的向量启动用户代码


上述方法是否可以翻译为在ARM M3上使用?

我认为“随波逐流”的表达在这里适用。你试图做一些手臂不打算做的事情,所以我认为你在给自己制造不必要的问题。将应用程序置于引导加载程序之上只需要在不同的地址链接,然后将VTOR寄存器设置为该地址。

两个应用程序中的一个必须链接到更高的内存,即用户应用程序或引导加载程序。我只是建议移动引导加载程序,这只需执行一次,而不必麻烦用户将每个应用程序移动到一个特殊的地址。哪里有参考资料表明ARM不是设计用来这样做的?两个应用程序中的一个必须链接到更高的内存,即用户应用程序或引导加载程序。我只是建议移动引导加载程序,这只需执行一次,而不必麻烦用户将每个应用程序移动到一个特殊的地址。在进入高内存中的引导加载程序时,以及在启动位于0x0的用户应用程序之前,需要设置VTOR。我认为您建议应用程序在0x0重新刷新向量。当您重新启动时,您的应用程序将在0x0矢量之后启动,但引导加载程序将永远不会运行,直到您重新刷新启动矢量。否。0x0(8字节)处的SP&PC向量将始终指向高内存中的引导加载程序,并且不会更改。除SP和PC向量外,所有应用向量将像往常一样在0x0加载。然后,在下载用户应用程序的过程中,前8个字节(SP和PC)将不会放在0x0,而是放在高内存中。当引导加载程序想要启动应用程序时,它会使用它在下载过程中保存在高内存中的SP&PC向量。我更喜欢引导加载程序和它需要运行的任何东西完全独立于任何加载的应用程序。通过使用指向引导加载程序的应用程序加载向量,您依赖于应用程序的行为来运行引导加载程序。对我来说,引导加载程序是不可变的,不管应用程序做什么,引导加载程序总是可以运行并加载新的应用程序。无论如何,祝你的方案好运。这样做的另一个副作用下面没有提到——如果你用任何其他工具(调试器)刷新你的用户代码,你将绕过引导加载程序向量表修改方案。然后需要重新启动引导加载程序来修复向量表,并将用户代码上载到引导加载程序。这比一次性修改起始地址要麻烦得多。