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:不通过闪存 API 在特定地址上对数据进行编程

Guru**** 2391415 points


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

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/677746/f28m35h52c-data-not-being-programmed-on-certain-address-through-flash-api

器件型号:F28M35H52C

伙计们、

我再次提出另一个问题。  

尝试通过 M3端的引导加载程序更新应用软件时、我遇到了有关应用软件生成的 Intel 十六进制格式的问题。   

因此、在我的引导加载程序应用中、我使用 以下 API 一次对全部64位或8字节的数据进行编程。 其中  data_buffer  是指向我的8个字节数组的指针。  

oReturnCheck = fapi_issueProgrammingCommand ((UINT32 *) flash_address、data_buffer、8、0、0、 Fapi_AutoEccGeneration);

来自应用程序项目生成的 Intel hex 文件的每一字节数据都将得到良好的编程、直到我到达以下两行:

 044DA000200030B906

:204DA4004000400040058000400050004005900040000004005A000400070004005B0001B


当我解析第一行时、地址 I 窗体为0x00214DA0、数据 I 窗体为0x200030B9。 现在、由于我一次对8个字节进行编程、剩余的4个字节我写入0xFFFFFFFF 并传递 DATA_buffer。 该数据会得到很好的编程。  

但是当我到达地址为0x00214DA4的第二行时, 我想、由于在上一步中对该地址执行了 ECC 检查、我将无法使用我要写入的数据覆盖0xFFFFFFFF、因此当我验证闪存部分时、我最终会进入错误状态。  

下面是我的应用项目的"Memory"部分。 请注意、我将从0x0020C000开始应用闪存部分。

我能否得到一些提示,说明我应该在哪里进行更改,以便不会最终出现这种情况??

谢谢

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

    您是否可以根据 DATA_buffer 的大小来改变缓冲区大小? 在第一种情况下、应该是4、对吧?

    您将填充地址0x00214DA0 - 0x00214DA8并返回到0x00214DA4。 最好是根据您的需求填写地址。

    希望这个答案对您有所帮助。

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

    您好 Katta、

    我没有尝试过你的建议。 但这不会使 ECC 检查问题再次出现吗? 因为我需要根据我在上一篇文章中确认的内容至少对8个字节进行编程??  

    现在、我尝试的是使用旧版本的 TI ARM 编译器 TI v5.2.5、此问题消失了。 使用 TI v 15.12.6LTS 时、问题就会再次出现。  

    您能否确认是否可以使用 v5.2.5编译器?? 与最新版本相比、旧版本有何不同。 通过观察行为的变化,我看到一些内存填充方法发生了变化。

    谢谢

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

    是的。 它带来了 ECC 检查问题。 我没给您写过、尝试使用 DataOnly 选项。 无论如何、我会向编译器团队核实这一点。 请留出更多时间。

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

    我们仍在研究这个主题。

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

    您好 Katta、

    当然、请在您获得编译器团队的解释后更新我。 因为我需要向为我们提供 RTOS 解决方案的第三方软件供应商更新相同的版本!   

    谢谢

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

    您显示的十六进制实用程序输出...

    [引用 user="Preetham Kashyap"]

     044DA000200030B906

    :204DA4004000400040058000400050004005900040000004005A000400070004005B0001B

    [/报价]

    (笑声) 在规格范围内。  我同意奇怪的是,有一条长度为4的记录,后面是一条长度为32的连续地址的记录。  但这并不违反 Intel hex 格式的规范。

    [引用 user="Preetham Kashyap"]在我的引导加载程序应用程序中,我一次对64位或8字节数据进行编程

    这似乎违反了规范。  最好不要对您以 Intel hex 格式获得的记录的长度作出任何假设。

    话虽如此,我同意这是不方便的,我不知道为什么会发生这种情况。  如果您愿意、我们可以根据十六进制实用程序提交报告。  它不会报告错误、而是报告低效输出。  请注意、即使此报告导致十六进制实用程序发生更改、仍最好修改读取 Intel 十六进制格式的程序。

    谢谢、此致、

    乔治