• 状态 Resolved
  • 已锁定 已锁定
  • 回复 5 回复
  • 订户 1 订户
  • 视图 262 视图
  • 用户 0 会员在此处
选项
选项
相关

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.

[参考译文] F28M35H52C：C28编译器生成的 hex 文件上的闪存扇区对齐问题！

admin
Guru**** 2538930 points


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

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/725654/f28m35h52c-flash-sector-alignment-problems-on-c28-compiler-generated-hex-file

器件型号：F28M35H52C

大家好、

第一个问题：

之前、我在十六进制文件上对齐闪存扇区地址时遇到问题。 之后、建议对使用闪存的所有段使用 align (4)。 但是，现在 C28闪烁应用程序略有变化， 即使在使用 align 关键字之后，其中一个流中也有一个不完整的64位字？ 我已将整个 C28闪烁项目附加到这里。  

不完整的十六进制文件数据流：

:18A26000761F0280A8080006761F0280A80600069A0100060006A1
:20A26C007622761F01001A2400011A200003761F01061800FFFD1800FFFE761F0100CC0001

我的更改位于 Lab1_C28.c 文件中。 我只是将  uldelay 值增加到了  10000000。

我的.cmd 文件中是否还有其他需要考虑的内容？

第二个问题：

如果变量"uldelay"值为1000000、那么我的十六进制文件中看不到任何不完整的对齐。 因此，当我使用该十六进制文件对 C28自定义引导加载程序中的闪烁进行编程时，控制卡上的 LED 会以更高的频率闪烁，这是令人惊讶的吗？ 这怎么可能呢？ 我没有更改任何闪烁应用的闪存等待状态。 下面的同一 项目也用于此演示。  

 e2e.ti.com/.../blinky_5F00_c28.tar.gz

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

    关于从 hex 文件流式传输的数据：对齐链接器命令文件中64位边界上的段可确保该段从64位边界开始。 它不保证该段将在64位边界上结束。 这意味着未使用其余的64位(正确？)。 因此、您可以假设64位段中未使用的部分全部为1、对它们进行编程。 填充64位的另一种方法是(以便可以流式传输完整的64位)、使用链接器 cmd 文件中的 fill 限定符将所有1填充到未使用的存储器中。 希望这对您有所帮助。

    关于 LED 闪烁：您是否比较了 RAM 与闪存的闪烁？ 您说的闪存速度更快吗？ 请澄清。

    谢谢、此致、
    Vamsi
  • 0
    TI__Guru**** 2538930 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好、Vamsi、

    [引用 user="Vamsi Gudivada"]这意味着未使用其余的64位(正确？)。

    并不完全是64位。 例如、在下面的流中、编程到结束的地址为0x13A26B。  

    18A26000761F0280A8080006761F0280A80600069A0100060006A1

    下面一行的地址从0x13A26C 开始、而不是0x13A270！ 因此，使用这个以前的地址，当我尝试编程时，我将会得到一个程序 ECC 错误，就像在前一个情况中，闪存 API 已经计算 出0x13A26C 的 ECC，以及 RITE ?  

    20A26C007622761F01001A2400011A200003761F01061800FFFD1800FFFE761F0100CC0001

    那么我的问题是，为什么即使在链接器文件中使用 align (4)后也会获得这样的模式？  

    [引用 USER="Vamsi Gudivada]Hence、您可以假设64位段的未使用部分全部为1、对它们进行编程。 [/报价]

    我认为这会使我面对我刚才所说的同样问题。  

    [引用 user="Vamsi Gudivada">填充64位的另一种方法是(以便可以流式传输完整的64位)、使用链接器 cmd 文件中的 fill 限定符用所有1填充未使用的存储器。 希望这对您有所帮助。[/引述]

    这似乎是一个有趣的选择，我该怎么做？ 因为我的空穴在0x13A26C 到0x13A26F 之间吗？ 我尝试的是什么  

    FLASHC   ：origin = 0x13A000，length = 0x001F80，fill = 0xFFFF //必须用 FFFF 填充此边界中的每个位置，孔位置除外。

    那么，我如何准确地尝试这个选项呢？  

    [引用 USER="Vamsi Gudivada">关于 LED 闪烁：您是否比较了 RAM 与闪存的闪烁？ 您说的闪存速度更快吗？ 请澄清。[/报价]

    没有，我正在闪存中运行此项目，但我在使用 InitFlash()与注释 InitFlash()函数时看到了不同的行为。 如果您尝试运行我在第一个问题中附加的项目、您将看到我在这里尝试传达的内容。  

    谢谢  

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

    Preetham、

    好的、明白了。 如我所说、对齐64位边界上的段可确保它从64位边界开始。 但是、在段中、不同函数/变量的放置方式取决于编译器/链接器。 尝试使用"填充"选项(填充方式正常)、然后查看该选项是否适用于您的 case。 如果没有、我可以将其转发给编译器团队、他们可以为您提供更多见解。

    关于闪烁频率：我查看了您的代码、但未运行。 请注意，使用的 InitFlash()与未使用的闪存执行速度之间将存在差异。 当您不使用它时、闪存等待状态将为最大值(默认值) 0xF -除非之前执行的一些代码更改了它。 当您使用 InitFlash()时，将适当地配置等待状态，以便根据您配置的系统频率提供最佳性能。 此外，InitFlash()启用预取和数据高速缓存。 使用 InitFlash()时是否看到高频率？ 那么这是预期的。

    谢谢、此致、
    Vamsi

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

    您需要我们的编译器团队的帮助吗？这是否得到了解决？

    谢谢、此致、
    Vamsi
  • 0
    TI__Guru**** 2538930 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    Preetham、

    由于在过去两周没有听到您的声音、我将关闭此主题。
    希望您使用填充选项解决了该问题。
    您可以根据需要打开新帖子。

    谢谢、此致、
    Vamsi