This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] RTOS/TM4C1294NCPDT:引导加载程序被擦除

Guru**** 2568565 points


请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/798203/rtos-tm4c1294ncpdt-boot-loader-getting-erased

器件型号:TM4C1294NCPDT
主题中讨论的其他器件:TM4C123

工具/软件:TI-RTOS

大家好、我对 ARM、TI-RTOS 和引导加载程序比较陌生。 但是、我让所有这些都在我设计的另一个 TM4C123板上工作。 现在、我正在尝试让基于闪存的引导加载程序在 TM4C1294上工作、但遇到了问题。 似乎可以下载我的代码、但在下载完成后、我的引导加载程序已在闪存开始时被擦除。 我一直在努力解决这个问题、但现在还不幸运。 我的应用基于 TI-RTOS、我已将其构建调整为位于0x1000、并从调试器加载并运行在此位置。 但是、如前所述、无论 为调试器设置的擦除选项如何、执行此操作时都会擦除引导加载程序。 现在、我正在尝试在刷写引导加载程序代码后通过引导加载程序加载我的应用程序。 我的应用程序的 cmd 文件如下所示:

#define APP_BASE 0x00001000
#define APP_Leng 0x000FF000
#define RAM_base 0x20000000
#define RAM_Leng 0x00040000
存储器

  闪存(RX):origin = app_BASE,length = app_leng
   SRAM (rwx):origin = RAM_base,length = RAM_Leng
/*内存中的段分配*/
部分

   .text  :  > FLASH
#ifdef __TI_Compiler_version
#if __TI_Compiler_version >=15009000
   .TI.ramfunc:{} load=flash,run=SRAM,table (BINIT)
#endif
#endif
  .const :  > FLASH
   .cinit :  >闪存
   .pinit :  > FLASH
   init_array:> FLASH
   .data  :  > SRAM
   .bss   :  > SRAM
   .sysmem  :> SRAM
   .stack :  > SRAM
我已经使用一些挂钩构建了引导加载程序代码、以使板上的 LED 闪烁、因为它正在闪烁代码。 引导加载程序构建的 CMD 文件如下所示:

/*系统内存映射*/
存储器

   闪存(RX):origin = 0x00000000,length = 0x00001000
   SRAM (rwx):origin = 0x20000000,length = 0x00040000
/*内存中的段分配*/
部分

   组
   {
       .intvecs
       .text
       .const
       .data
   } load = FLASH、run = 0x20000000、load_start (init_load)、run_start (init_run)、size (init_size)
   组
   {
       .bss
       堆栈
   }run = SRAM、run_start (bss_run)、run_end (bss_end)、size (bss_size)、run_end (__stack_top)


我在调试器单步执行引导加载程序代码时不太幸运、因为它会自行重新定位。 有一次、我尝试在 BL_MAIN 中设置断点、但不确定这是否可行、似乎不稳定?  下载完成后、我的代码似乎出现在0x1000地址、但从0到0x1000的区域全部为0xFFFF、引导加载程序消失。 是的、当刷写应用程序时、我在 lmflash 中将偏移量设置为0x1000。 根据需要、我的 TI-RTOS 版本包括以下内容。  

/*在引导加载程序之后重新定位复位矢量和代码以从0x1000开始*/
Program.sectMap[".resetVecs"].loadAddress = 0x00001000;
引导加载程序正好位于4K 空间下面。 如果有任何想法或建议来解决这个问题、我们将不胜感激。 提前感谢您提供的任何帮助。
此致、
Bob Starr
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您好、Robert、
    我认为问题是您的 APP_BASE。 请将其更改为0x4000而不是0x1000。 请参阅数据表、每个闪存扇区为16kB。 将 APP_BASE 定义为0x1000时、该应用将占用与引导加载程序相同的扇区、引导加载程序的起始地址为0x0。 为了对应用固件进行编程、需要首先擦除将要对固件进行编程的扇区、这就是擦除引导加载程序所在的第一个扇区的原因。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    大家好、Charles、非常感谢部门规模的监督。 尝试在紧急模式下进行调试以使电路板发运。 我已将所有偏移调整为0x4000、我的应用程序仍从调试器运行、但将引导加载程序调整为0x4000后、引导加载程序不再工作。 现在查看调试器中的启动代码。 调试器似乎单步执行汇编代码。 但是、如果我在将引导加载程序复制到 SRAM 后放置一个断点、似乎永远不会出现这种情况。 尝试弄清该副本现在发生了什么情况。 我不能加快处理 ARM 汇编代码。 有些事情是重大的错误、似乎是在执行垃圾、仍在挖掘...

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    它现在正在工作、非常感谢您指出了我的网站。 感谢上帝,在 CB1处理我的案件之前,它被修复了。。。。 哈哈
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    尊敬的 Bob:
    您是否想与社区分享您做出了哪些改变以使其发挥作用?
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    我从基于 TM4C123的项目中复制了引导加载程序代码、并忽略了更大的16k 闪存页大小。 引导加载程序配置模板标题 BL_CONFIG.h.Tmpl (如下所示)中的注释表明1k 是所有 Tiva MCU 的闪存页面。 我假设我最初从这里提取了模板。  我将其从0x400更改为0x4000、它解决了我的问题。 可能需要更新 boot_loader 源配置头模板中的注释。 这让我失望、因为我假设所有 Tiva 都使用1K 页大小。

    谢谢、

    Bob

    //
    //
    //闪存中单个可擦除页的大小。  这必须是电源
    //共2个。  默认值1KB 表示内部的页面大小
    //所有 Tiva MCU 上的闪存和该值只应在以下情况下被覆盖
    //配置引导加载程序以访问页大小的外部闪存设备
    //与此不同。
    //
    //取决于:无
    //不包括:无
    //要求:无
    //
    //
    #define FLASH_PAGE_SIZE        0x00004000
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    尊敬的 Bob:
    谢谢。 我认为您已经将所有引用更改为0x4000、但仍然不起作用、因此我询问您是否有其他更改以使其最终工作。 如果仅将 FLASH_PAGE_SIZE 设置为0x4000、那么您是对的、这也需要更改。 谢谢!
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    我更改了所有内容、但该值和引导加载程序不起作用。 我的应用程序在调试器中以新的16k 偏移运行(正如预期的那样)、不再覆盖闪存、但引导加载程序停止工作、因为我也没有将页面大小更改为0x4000 (注释将我关闭)。 引导加载程序仍会以1k 的速度运行、但由于页面大小错误、随后会被擦除。 无论如何、只需更新 BL_CONFIG 模板中的注释、可能会为其他人节省大量沮丧。 再次感谢您的帮助。