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.

[参考译文] TMS320F28022-Q1:使用闪存程序 API 将16个字编程到闪存中、但有时全部为0xFF

Guru**** 2390755 points


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

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1237528/tms320f28022-q1-using-flash-program-api-to-program-16-words-into-flash-but-sometimes-all-0xff

器件型号:TMS320F28022-Q1

BU 先生/女士、  

客户使用 2802x_FlashAPI_BootROMSymbols_v2.01.lib 对 F28022的闪存进行编程。 过程是:首先、接收包含16个字的数据包(16位字、或者您可以说总共32个字节);其次、通过调用闪存 API 来将其编程为以下代码:  

如图所示、编程后、他们将进行验证、但验证结果(即代码中的 u16VerifyStatus)不会 用于进一步判断或诊断。 但是、编程状态、即 u16ProgStatus 将用于进一步判断或诊断。  

在我看来,以上程序对编程来说是很好的。 但客户发现自己领域的一些芯片出现了以下现象。 也就是说、一些数据包不能编程到闪存中、但是结果是0xFFFF、如下图所示。 并且在几次测试中、相似的芯片将具有不同的闪存地址来解决这个问题、这意味着软件应该没问题。 最重要的是,u16ProgStatus  在这种情况下是成功的。 由于  客户系统中未使用 u16VerifyStatus、因此  在这种情况下不知道 u16VerifyStatus。  

请帮助分析上述问题并提供您的建议。

我有以下疑问、请给出您的指导:  

1.为什么   u16ProgStatus 在这种情况下仍然成功? Flash_Program API 返回的成功状态意味着什么? 这只意味着编程命令被成功释放至闪存状态机?  

2.如果可能是电源不稳定造成的问题? VDDIO 用于为闪存供电。 如果在闪存内容编程期间 VDDIO 降低、这可能会导致上述问题吗?  

感谢你的帮助。  

此致、  

将会  

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

    您好、Will、

    此任务分配给了我们的 F28022闪存专家;他们会联系您。

    谢谢。此致、
    瓦姆西

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

    将会、

                 是否存在客户未使用 u16VerifyStatus 的原因?

    Unknown 说:
    2. 如果可能、问题是电源不稳定导致的? VDDIO 用于为闪存供电。 如果在闪存内容编程期间 VDDIO 降低、这可能会导致上述问题吗?  [/报价]

    您能否私下与我分享功率级原理图?

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

    Hareesh、  

    是否有原因客户未使用 u16VerifyStatus?

    因为客户认为编程状态可以为最后一次的编程操作提供足够的信息。 这就是为什么我怀疑   u16ProgStatus 在这种情况下仍然是成功的。 请回答我的第一个问题。  

    您能否私下与我分享功率级原理图?

    我将向客户索取此文件。 但由于该问题只能在客户现场、即车辆测试中出现、因此从原理图视图来看、功率级设计可能没有问题。 从电路原理来看、它是否会导致该问题?  

    此致、  

    将会  

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

    将会、

       我已要求同事对 API 有更深入的了解、以回答您的第一个问题。  

    我要向客户索取此文件。 但由于该问题只能在客户现场、即车辆测试中出现、因此从原理图视图来看、功率级设计可能没有问题。 从电路原理来看、它是否会导致该问题?  [/报价]

    我不明白你在这里想说什么。 如果器件在编程期间"无法获得电流"、则可能导致一些随机错误。  

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

    Hareesh、  

    我的第二个问题是:在对长度为32字节的闪存进行编程期间、如果电源不稳定、例如 VDDIO 低至3.0V 或其他值、但不对器件进行 BOR/POR、编程操作是否会失败、闪存中的内容仍为0xFFFF?  

    我想找出问题的根本原因(有时闪存编程操作失败、内容仍然为0xFFFF)、可能需要电源供电。 其他分析方向也会很有帮助、请提供您的指导、谢谢。  

    此致、  

    将会  

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

    将会、

       这需要由闪存 API 专家来处理。 他目前正在度假、应于周一返回纽约。 感谢您的耐心。

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

    Hareesh、  

    请帮我们安排此问题的分析日程、客户正在催促我给出回复。  

    如果电源不是导致此问题的原因、BU 侧可提供更多可能性、客户可以尝试复制。  

    谢谢。此致、  

    将会  

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

    它可能是由闪存包装程序逻辑/存储器阵列瞬态故障引起的、只是某种程度的头脑风暴错误吗? 我们以前是否遇到过此类问题?  

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

    将会、

    在您的第一篇文章中、内存窗口的图片中、0xFF (已擦除)的字数是否与客户每次都要编程的块大小相对应?  这意味着、如果我们通过编程方式跳过模块、我们将看到相同的闪存模式?

    我查看了 API 指南、程序函数也在其例程中执行验证;因此如果内容不匹配、则会实时返回一个错误。

    如果未返回错误、则表示程序函数已验证传递的数据是否已正确编程。

    在这种情况下、这可能意味着:

    1)在编程循环中、由于某种原因、我们跳过了闪存块;因此不会调用程序函数。

    2)程序函数作为缓存被传递0xFF 作为对闪存进行编程的缓冲区、因此返回 PASS

    至于客户对闪存进行编程的方式、我们是否知道他们是在编程前擦除所有闪存、还是根据需要擦除各个扇区?  我们是否具有客户发现此问题的绝对闪存地址;以及在其系统/流程中擦除/编程的闪存扇区?

    此致!

    马修

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

    Matthew、您好!  

    它们在编程前擦除所需的扇区、但不擦除整个闪存。 看到此问题时、它们不监控闪存地址。  

    字量0xFF (已擦除)是否与客户每次都编程的块大小相对应?  [/报价]

    是的、正确。 "失败"编程大小是他们每次想要编程时的帧块大小。 所以、我同意您的看法、这更像是流/帧接收问题。  

    但我仍想从故障模式影响分析(FMEA)中与您联系、如果硬件中的瞬态故障可能会导致这种"故障模式"、即编程失败和编程状态仍然正常? 我们以前是否遇到过类似问题? 我需要此信息的原因是要彻底消除客户的疑虑。   

    谢谢。此致、  

    将会   

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

    将会、

    我还没有遇到过硬件故障带来的此类问题、这两个问题都匹配了程序大小、而且返回了一个已擦除的值(0xFFFF)。  

    如果存在初始编程问题、正如我们所说的、API 将返回故障。

    如果有一段时间受到干扰、我就不会希望数据被统一/擦除、或者限制在不同的字区域。

    此致!

    马修

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

    明白了。 谢谢 Matthew。  

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

    Matthew、您好!  

    来自客户的另外一个问题:如果 Flash_PROGRAM API 已完成验证、为什么需要 Flash_verify?  

    此致、  

    将会  

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

    Matthew、您好!  

    您可以回答上述问题吗?  

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

    将会、

    很抱歉耽误你的时间、我正在与团队中的其他一些人就此进行谈话。  请在此处期待收到 tomm 的回复。

    此致!

    马修

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

    这两种验证方法的区别在于、验证函数使用 CPU 读取来根据已知映像检查闪存的内容;而程序函数的验证是实时检查基于设置的闪存程序是否已通过。

    因此、在客户的情况下、如果我们认为问题可能是程序功能全部通过了0xFFFF、如果将正确数据与之进行了比较、最终验证可能会捕获到该问题。

    不过、在这种情况下、如果使用仍然传递的不正确的传递值立即执行验证。

    此致!

    马修

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

    Matthew、您好!  

    感谢您的答复。 如何定义" 实时检查"、低级机制仍是 CPU 读取以检查的机制? 或使用其他一些硬件方法、例如电压比较器?  

    此致、  

    将会  

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

    将会、

    第二条语句正确、在程序函数内部进行的"验证"操作是为给定字编程的位的电压电平返回到已编程位的正确电平。  

    因此这依赖于闪存内的某些电压比较来表示编程成功。

    此致!

    马修