[参考译文] TMS320F28388D：特定闪存扇区之间来回分支

尊敬的 Pranay：

感谢您的提问。 我必须在第二天或第二天内回复您。

此致、

查尔斯

Pranay,  

q1)在图片中包含引导命令、因为 M4尚未设置引导模式、因此它驻留在等待引导模式。  

Q2)在从一个应用程序跳转到另一个应用程序之前、您可能希望存储上一个应用程序正在使用的内容的临时值。 但由于每个应用都位于闪存中、因此我想看看每个分扇区应用的 RAM 用量是多少。

Q3)可以、只要扇区未同时编程和擦除、因为这些扇区位于同一组中。

Q4)注意确保从先前的函数返回时、您将从哪个输入地址开始、以及哪些变量会丢失其值。

Q5/6)对于固件跳转示例、我将以实时固件更新(F280039C)为例。 我知道这是我们提到的 F28388D 器件、但我必须研究存储器以查看该切换应用是否存在一个示例。  

将在明天进一步完善这些答案。

谢谢。此致、

查尔斯

Charles

我先评论一下您的答案。

Q2)可能不需要存储临时值、因为编译器将使用堆栈管理这些临时值。

如果在 APP2中位于特定函数中、并且分支到 APP1、则 APP2的栈将包含必要的临时变量。

不过、APP1、APP2、APP3的 RAM 使用情况是个不错的选择、必须检查任何重叠情况。 具体而言、确保避免重叠、包括使用堆栈。

Pranay,

"AP1将在我们执行 POR 时首先引导、并从 APP1调用 APP2。

我们的实现可从 APP2对 APP3/APP1进行编程、并在需要时跳转到 APP3/APP1。"

如果我理解正确、则 APP2和 APP3为应用程序 FW、APP1是引导加载程序(或您称之为 SSBL)。 那么、应用程序 FW (APP2)为什么会覆盖/编程引导加载程序(APP1)？

由于只有1个闪存组、因此可以设置 APP2程序 APP1 (如果您实际上希望这么做的话)。 但是、由于您无法同时读取和写入闪存组、因此您需要运行 APP2的一部分来执行 RAM 中的闪存编程和闪存 API 库。

我们没有针对 F2838x 的此类示例。 我们拥有的 LFU 示例适用于 C28x 端(不是 CM 端)、可在参考设计 TIDM-02011中找到。

谢谢。

Sira

尊敬的 Sira 和 Charles：

感谢您的回复。

是的、我们确保了 RAM 和闪存扇区不会在引导加载程序和应用程序固件之间重叠。

pu lin1 说：

您需要运行 APP2的部分以执行闪存编程+来自 RAM 的闪存 API 库

在 APP1和 SSBL 链接器文件中、我们确保了它们各自的 闪存 API 库位于 RAM 中。 请找到随附的链接器文件供您参考、如果需要在链接器中调整任何内容、请更正我。

Unknown 说：

Q3)可以，只要扇区不同时编程和擦除，因为扇区在同一个组中即可

我们使用 SSBL 的时间很长、也知道这一点、我们已经确保闪存驻留在 RAM 部分、不会被同时擦除和读取/写入。

问题7： 从下面的链接中可以看到一些称为启动代码或初始化代码的东西 、通常在 FSBL 中执行、 我认为,我们确实需要某种类似的启动代码,然后我们从引导加载程序跳到 APP1 FW 或反之亦然,以确保正确的分支发生.

https://www.iotality.com/arm-cortex-m4-startup-code/

https://stackoverflow.com/questions/59458156/why-stack-pointer-need-to-be-updated-before-jumping-to-application-from-bootload

https://www.ti.com/lit/ug/spru430f/spru430f.pdf - 514页号

否则，如果我们在从 ssbl 跳转到 APP1之前不进行任何初始化，这不意味着 APP1仍在 SSBL 上下文中运行吗？

问题8： 在通过 APP1 FW 刷写引导加载程序后、我是否需要执行或写入任何内容作为启动代码、因为我看到当通过 JTAG 对同一个引导加载程序进行编程后、它会在 POR 后正确地从 FSBL 跳转到引导加载程序、 但是、当通过 APP1 FW 对相同的.txt 进行编程、然后执行从 FSBl 跳转到 SSBL 的 POR 时、就不会发生这种情况、并且根据目标配置执行卡在0x1818处。

为了便于参考、我已经共享了通过 APP1 FW 和 JTAG 写入的.xtx 文件、我看到 在这两种情况下、从闪存读取到 JTAG 时、没有区别。 因此、我们可以从列表中消除闪存数据写入不匹配问题。

我在这里遗漏了什么？ 您能否确认并介绍有关 JTAG 除了写入闪存之外还执行哪些额外操作来使控制器从 FSBL 跳转到引导加载程序的信息？

为了调试卡在0x1818位置的代码、TRM 说如果执行卡在 WAITBOOT 模式并等待来自 CPU1的引导命令、就会看到此错误、因此我尝试从 CPU1发送器件引导 CM 命令、但这对我们没有帮助。

-普拉奈。

尊敬的 Pranay：

我需要一些时间来确认这些事情,将在星期二回到你。

谢谢。

查尔斯

Pranay,

您能否说明您正在使用的术语- FSBL 和 SSBL？

在引导器件时、我假设 APP1先运行、然后将控制权转移到 APP2。 如果是这种情况,那么在每种情况下,在运行 APP1或 APP2之前,应该在运行相应的( APP1或 APP2的) main ()之前运行"C 初始化例程"。

我知道这对于 C28x CPU 来说是真的、我确信这也适用于 CM 内核。 正是这样、它能够设置 C 语言环境、执行所有变量的初始化、等等、并正确运行相应的软件。

在 C28x 中、这由 TI 编译器提供为 c_int00。 这是被调用的函数,它会自动调用 main ()。 从引导加载程序分支到应用程序时、我将分支到应用程序中调用 c_int00的位置。 通常、该文件位于 codestartbranch.asm。

我不知道对应的文件名等在 CM 方面是什么、但方法应该是相同的。

谢谢。

Sira

另外、您没有回答我之前的问题。 请确认下面的粗体陈述中是否存在拼写错误。

每当我们执行 POR 时、将首先引导 AP1、并从 APP1调用 APP2。

我们的实现可从 APP2对 APP3/APP1进行编程、并在需要时跳转到 APP3/APP1。

正确的陈述是否如下？

我们的实现可从 APP1对 APP2/APP3进行编程、并在需要时跳转到 APP2/APP3。

尊敬的 Sira：

让我重复一下问题陈述以避免混淆。

CM 控制器中有两个定制应用。
1. App1 (我们指的是 SSBL-第二阶段引导加载程序)。
   因为该应用程序将用于执行现场固件更新。
   在 POR 第一个之后、将加载基于闪存扇区数据的 App1。 以及编程模式/引导模式。
   它将跳转至实际应用程序固件 App2。
   一些其他延迟。 它将从 UART 接收数据并将固件加载到 App2位置。
   所有这些活动都按预期进行。
2. App2 (实际的自定义用户应用程序)
   根据要求、如果没有任何新的植入。 我们将使用 App1进行更新。 如上所述。
   
我现在的要求是、我需要从 App2更新 App1固件。
南 为了执行该操作，我使用了 App2并加载了 App1()并将其写入指定位置。
如果我执行 POR、则 App1和 App2均未运行。

注意：默认情况下，App1将从 JTAG 加载。 在我的当前要求中、我使用 App2加载了 App1。

通过 JTAG 内存浏览器验证是否有数据、从 JTAG 加载 App1数据时以及从 App2加载 App1数据。
保持不变。 我的初始注释"program_flsh_read_data.zip"中已附加了该文件。

您能告诉我一下吗？ 我如何能够继续进行进一步的工作。 如果需要进一步的输入、请告诉我们。

谢谢。

普拉奈

Pranay,

使用应用程序 FW 更新 SSBL 对我来说似乎是一个奇怪的用例、但这就是您要尝试做的。

您说闪存内容在使用 JTAG 加载时与 APP2更新 APP1时是相同的(对于 APP1闪存扇区)。 因此这必须意味着正在对其进行正确编程。

1.我认为您正在使用闪存启动模式？ 当您在更新 APP1后复位器件时、控制权到达何处？ 它应到达闪存入口点。

2.在 C28侧、当您使用 JTAG 加载程序时、 由于调试器被连接、它将使用仿真引导模式、然后最终分支至闪存入口点。 一旦您使用 JTAG 对 APP1进行编程、然后复位器件、它的行为是否符合预期？

谢谢。

Sira

Sira,

pu lin1 说：

1. 假设您正在使用闪存启动模式？ 当您在更新 APP1后复位器件时、控制权到达何处？ 它应转至闪存入口点。

我们将使用闪存引导模式、在执行静止操作时不会跳转到闪存入口点、我们通过 JTAG 知道它得到了成功

为了调试卡在0x1818位置的代码、TRM 说如果执行卡在 WAITBOOT 模式并等待来自 CPU1的引导命令、将会看到此错误、 因此、我尝试从 CPU1发送 Device boot CM 命令、但这没有帮助我们 either.it 正卡在上面提到的其他两个位置。

您能否帮助我们了解并调试 POR 发生时执行的位置、以及在将数据写入闪存扇区之前和之后需要遵循的必要步骤以帮助控制器引导。

pu lin1 说：

2. 在 C28侧、当您使用 JTAG 加载程序时、 由于调试器被连接、调试器将使用仿真引导模式、然后最终分支至闪存入口点。 一旦您使用 JTAG 对 APP1进行编程、然后重置器件、它的行为是否符合预期？

当 复位时通过 JTAG 对 APP1进行编程时、它正在引导并行为符合预期

谢谢

普拉奈

Pranay、我来和一位团队成员谈谈这个问题、然后马上与您联系。

谢谢。

Sira

尊敬的 Sira：

 我正在等待这从过去的10天,这方面的任何更新请让我知道 .

谢谢。

普拉奈

Pranay,

"我知道,我知道你在胡说什么。" 我已再次向我的同事征求这方面的建议。

谢谢。

Sira

ECC 是否也在两种情况(JTAG 负载和 APP2负载)之间匹配 APP1？ ECC 空间记录在数据表中。

尊敬的 Sira：

已检查这两种情况的 CM_FLASH_ECC_REGS 寄存器状态，它们是相同的，请找到以下两种情况的.txt 文件。

如果是闪存写入,我们应该禁用 ECC ,那么只有闪存写入是可行的。 我们是否期望做任何其他事情,除了这一点?
请告诉我们,如果有什么需要特别写入 ECC 寄存器在闪存写入.

谢谢。此致、

普拉奈

e2e.ti.com/.../eccregisterthrough_5F00_throughapplication.txte2e.ti.com/.../eccregisterthrough_5F00_throughJtag.txt

尊敬的 Pranay：

为什么要禁用 ECC 来执行闪存写入？  在启用 ECC 的情况下、闪存写入过程中会遇到哪些问题？ 请联系我们。

谢谢。此致、

瓦姆西

尊敬的 Vamsi：

如果我们不禁用 ECC (Flash_disableECC),我们无法将全部数据写入闪存扇区,在闪存写入执行之间将中断一半的数据写入闪存扇区。

如果我们禁用 ECC、我们就能够将整个数据写入闪存扇区。

默认情况下、我们使用 Flash_disableECC 以便成功写入所有数据。

为了便于参考、我提供了 txt、其中显示了 Flash_disableECC 已执行情况、而未执行情况。

在调试模式下、它显示执行将转到调试代码之外。 请参阅随附的屏幕截图。

e2e.ti.com/.../Flashwrite_5F00_With_5F00_ECC_5F00_Disable.txt

e2e.ti.com/.../Flashwrite_5F00_Without_5F00_ECC_5F00_disable.txt

谢谢

普拉奈

尊敬的 Pranay：

好的、必须先修复编程问题-启用 ECC 不应导致任何问题。  您已确认两个案例的映像相同。  并且在通过 JTAG 加载时可以正常工作、但在使用您的应用进行编程时无法正常工作。

1)使用应用程序中的 Flash API,是否正在使用 Fapi_Data 模式进行编程? 还是 Program (程序)命令的 Fapi_Auto EccGeneration 模式？  使用 AutoEccGeneration 方法避免 ECC 错误。

2) 2)编程时、起始地址应始终在64位或128位(首选128位)上对齐。   

3)使用 Fapi_Auto EccGeneration 编程时，请确保提供所有64位/128位(取决于是编程64位还是128位)。  如果提供部分数据、以后将无法对剩余数据重新编程、因为在提供部分数据本身时会对 ECC 进行编程。

4) 4)编程后检查 FMSTAT 值吗？  您是否看到其中有任何错误？

5) 5)此外、您能否在两个用例之间附加 ECC 空间数据？

谢谢。此致、
瓦姆西

您好，Vamsi，

chen chen2 说：

1)要使用应用程序中的闪存 API 进行编程，您是否正在使用 Fapi_Data？ 还是 Program (程序)命令的 Fapi_Auto EccGeneration 模式？  使用 AutoEccGeneration 方法避免 ECC 错误。

1.我们正在使用 Fapi_Data mode ,尝试使用 AutoEccGeneration 方法而不进行 ECC 解析,面临的问题是我们只能将一半的 txt 文件数据写入闪存。 为了便于参考、我分享了文本文件

e2e.ti.com/.../FlashWrite_5F00_Fapi_5F00_dataonly.txte2e.ti.com/.../FlashWrite_5F00_Fpi_5F00_AutoEccGen.txt

chen chen2 说：

2)编程时，起始地址应始终在64位或128位上对齐(最好是128位)。  [/报价]

2.入口点为0x210000，与128位和64位对齐

chen chen2 说：

3)使用 Fapi_Auto SceGeneration 进行编程时，请确保提供所有64位/128位(取决于是编程64位还是128位)。  如果提供部分数据，则以后无法重新编程剩余数据，因为当您提供部分数据本身时，ECC 会进行编程。

如上面的文本文件所示、我们无法编写、但我们正在使用的 txt 文件是从 CCS 应用基于链接器文件生成的。 正如您提到的 、地址应与64 ot 128位对齐、如果未对齐、您可以为我提供任何替代解决方案、就像需要在链接器文件中进行任何更改来对齐数据一样。

chen chen2 说：

4)编程后是否检查 FMSTAT 值？  您是否看到其中有任何错误？

4.是的、我在写后检查了整个 CM FLASH Cntrl 寄存器两种情况都是一样的、我已经给您参考 reg data txt 文件

e2e.ti.com/.../flashCntrl_5F00_Reg_5F00_fpiAutoEcc.txte2e.ti.com/.../flashCntrl_5F00_Reg_5F00_fpidataonly.txt

chen chen2 说：

5)此外，您能否在两个案例之间附加 ECC 空间数据？

5. ECC 空间数据是什么意思? 它是一个寄存器还是闪存地址，如何访问它？

谢谢。此致、

Pranay.  

[/quote]

尊敬的 Pranay：

我今天不在办公室；我将能够回顾这篇文章、并在一两天内与您联系。

谢谢。此致、
瓦姆西

尊敬的 Pranay：

感谢您提供的信息。

1) NMI 处理程序结束的原因应该是 ECC 错误-因为您没有对 ECC 进行编程(您正在使用 Fapi_Data )。

2) 2)我不是只讨论应用程序入口点-我是说您为编程命令提供的每个地址都应对齐(您可能已经在闪存 API 指南和示例中看到过这一点)。

3) 3)您是否可以使用 align (8)签入链接器命令文件以确保映射到闪存的所有段都是对齐的？

4) 4)抱歉、我无法查看整个寄存器转储。  编程命令之后、您可能已经在闪存 API 使用示例/指南中注意到、您需要检查命令的状态(请查看闪存 API 指南中的 FMSTAT 寄存器)。  请告诉我其中是否显示了任何错误。

5) 5)它是数据表存储器映射中提供的存储器区域。  但是、由于您已确认未对 ECC 进行编程、因此现在无需提供此信息。  

以下 常见问题解答页面可能会为您提供帮助：   

a.有关 C2000器件的闪存 API 使用方法的[常见问题解答]：  

     https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/951668 

b.[常见问题解答]有关闪存 ECC 在 C2000器件中的使用的常见问题解答-包括 ECC 测试模式、链接器 ECC 选项：  

     https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/951658 

谢谢。此致、
瓦姆西

尊敬的 Vamsi：

chen chen2 说：

1)您在 NMI 处理程序中结束的原因应该是 ECC 错误-因为您没有对 ECC 进行编程(您正在使用 Fapi_Data)模式。

1.我们不是在执行闪存写入时,而是在下电上电后才结束 NMI ,此时我们要写入闪存的所有数据都已写入。

2.我们看到 CPU1尝试引导 cm 时、在下电上电后的一段时间内它在 NMI 中被击中。

chen chen2 说：

3)您能否检查链接器命令文件，以确保映射到闪存的所有部分都已使用 align(8)？

3.已检查链接器文件映射到闪存的所有段都使用 align (8)对齐、请参阅下面的文件 SSBL 和应用程序链接器

//Application Firmware Linker file
MEMORY
{
   /* Flash sectors */
   CMBANK0_RESETISR : origin = 0x00210000, length = 0x00000008 /* Boot to Flash Entry Point */
   CMBANK0_SECTOR13 : origin = 0x00200000, length = 0x00000008
   CMBANK0_SECTOR0  : origin = 0x00200008, length = 0x00003FF7
   CMBANK0_SECTOR1  : origin = 0x00204000, length = 0x00004000
   CMBANK0_SECTOR2  : origin = 0x00208000, length = 0x00004000
   CMBANK0_SECTOR3  : origin = 0x0020C000, length = 0x00004000
   CMBANK0_SECTOR4  : origin = 0x00210008, length = 0x00003FF7
   CMBANK0_SECTOR5  : origin = 0x00220000, length = 0x00010000
   CMBANK0_SECTOR6  : origin = 0x00230000, length = 0x00010000
   CMBANK0_SECTOR7  : origin = 0x00240000, length = 0x00010000
   CMBANK0_SECTOR8  : origin = 0x00250000, length = 0x00010000
   CMBANK0_SECTOR9  : origin = 0x00260000, length = 0x00010000
   CMBANK0_SECTOR10 : origin = 0x00270000, length = 0x00004000
   CMBANK0_SECTOR11 : origin = 0x00274000, length = 0x00004000
   CMBANK0_SECTOR12 : origin = 0x00278000, length = 0x00004000
   GRLBOOTPGMMODE 	: origin = 0x0027C000, length = 0x00004000

   C1RAM            : origin = 0x1FFFC000, length = 0x00001FFF
   C0RAM            : origin = 0x1FFFE000, length = 0x00001FFF

   BOOT_RSVD        : origin = 0x20000000, length = 0x00000800 /* Part of S0, BOOT rom will use this for stack */
   SRAM             : origin = 0x20000800, length = 0x0000F7FF
   E0RAM            : origin = 0x20010000, length = 0x00003FFF

   CPU1TOCMMSGRAM0  : origin = 0x20080000, length = 0x00000800
   CPU1TOCMMSGRAM1  : origin = 0x20080800, length = 0x00000800
   CMTOCPU1MSGRAM0  : origin = 0x20082000, length = 0x00000800
   CMTOCPU1MSGRAM1  : origin = 0x20082800, length = 0x00000800
   CPU2TOCMMSGRAM0  : origin = 0x20084000, length = 0x00000800
   CPU2TOCMMSGRAM1  : origin = 0x20084800, length = 0x00000800
   CMTOCPU2MSGRAM0  : origin = 0x20086000, length = 0x00000800
   CMTOCPU2MSGRAM1  : origin = 0x20086800, length = 0x00000800
}

SECTIONS
{
   .resetisr        : > CMBANK0_RESETISR,FILL=0
   .vftable         : > CMBANK0_SECTOR8,ALIGN(8) /* Pranay, 07July'22,Application placed vector table in Flash, This shall not be collided with any other flash sectors*/
   .vtable          : > SRAM /* Application placed vector table in RAM*/
   .text            : >> CMBANK0_SECTOR5 | CMBANK0_SECTOR6, ALIGN(8)
   .cinit           : > CMBANK0_SECTOR5 | CMBANK0_SECTOR6, ALIGN(8)
   .pinit           : >> CMBANK0_SECTOR5 | CMBANK0_SECTOR4,ALIGN(8)
   .switch          : >> CMBANK0_SECTOR5 | CMBANK0_SECTOR4,ALIGN(8)
   .sysmem          : > SRAM
   .binit 			: > CMBANK0_SECTOR4

   .stack           : > C0RAM | C1RAM
   .ebss            : > C1RAM
   .econst          : >> CMBANK0_SECTOR5 | CMBANK0_SECTOR6| CMBANK0_SECTOR4,ALIGN(8)
   .esysmem         : >> C1RAM | C0RAM //heap
   .data            : > SRAM
   .bss             : >> SRAM | E0RAM |C1RAM
   .const           : {} LOAD = CMBANK0_SECTOR5 | CMBANK0_SECTOR6| CMBANK0_SECTOR7,ALIGN(8)
   							RUN = SRAM,
   							LOAD_START(constLoadStart),
   							LOAD_SIZE(constLoadSize),
   							LOAD_END(constLoadEnd),
   							RUN_START(constRunStart),
   							RUN_SIZE(constRunSize),
   							RUN_END(constRunEnd)

    MSGRAM_CM_TO_CPU1 : > CMTOCPU1MSGRAM0, type=NOINIT
    MSGRAM_CM_TO_CPU2 : > CMTOCPU2MSGRAM0, type=NOINIT
    MSGRAM_CPU1_TO_CM : > CPU1TOCMMSGRAM0, type=NOINIT
    MSGRAM_CPU2_TO_CM : > CPU2TOCMMSGRAM0, type=NOINIT

    .TI.ramfunc : {-l F2838x_CM_FlashAPI.lib} LOAD = CMBANK0_SECTOR5 | CMBANK0_SECTOR6 | CMBANK0_SECTOR7,
						                           RUN = SRAM,
						                           LOAD_START(RamfuncsLoadStart),
						                           LOAD_SIZE(RamfuncsLoadSize),
						                           LOAD_END(RamfuncsLoadEnd),
						                           RUN_START(RamfuncsRunStart),
						                           RUN_SIZE(RamfuncsRunSize),
						                           RUN_END(RamfuncsRunEnd),
						                           ALIGN(8)
}

/*
//===========================================================================
// End of file.
//===========================================================================
*/

//SSBL Linker File
MEMORY
{
   /* Flash sectors */
   CMBANK0_RESETISR : origin = 0x00200000, length = 0x00000008 /* Boot to Flash Entry Point */
   CMBANK0_SECTOR0  : origin = 0x00200008, length = 0x00003FF7
   CMBANK0_SECTOR1  : origin = 0x00204000, length = 0x00004000
   CMBANK0_SECTOR2  : origin = 0x00208000, length = 0x00004000
   CMBANK0_SECTOR3  : origin = 0x0020C000, length = 0x00004000
   CMBANK0_SECTOR4  : origin = 0x00210000, length = 0x00010000
   CMBANK0_SECTOR5  : origin = 0x00220000, length = 0x00010000
   CMBANK0_SECTOR6  : origin = 0x00230000, length = 0x00010000
   CMBANK0_SECTOR7  : origin = 0x00240000, length = 0x00010000
   CMBANK0_SECTOR8  : origin = 0x00250000, length = 0x00010000
   CMBANK0_SECTOR9  : origin = 0x00260000, length = 0x00010000
   CMBANK0_SECTOR10 : origin = 0x00270000, length = 0x00004000
   CMBANK0_SECTOR11 : origin = 0x00274000, length = 0x00004000
   CMBANK0_SECTOR12 : origin = 0x00278000, length = 0x00004000
   CMBANK0_SECTOR13 : origin = 0x0027C000, length = 0x00004000

   C1RAM            : origin = 0x1FFFC000, length = 0x00001FFF
   C0RAM            : origin = 0x1FFFE000, length = 0x00001FFF

   BOOT_RSVD        : origin = 0x20000000, length = 0x00000800 /* Part of S0, BOOT rom will use this for stack */
   SRAM             : origin = 0x20000800, length = 0x0000F7FF
   E0RAM            : origin = 0x20010000, length = 0x00003FFF

   CPU1TOCMMSGRAM0  : origin = 0x20080000, length = 0x00000800
   CPU1TOCMMSGRAM1  : origin = 0x20080800, length = 0x00000800
   CMTOCPU1MSGRAM0  : origin = 0x20082000, length = 0x00000800
   CMTOCPU1MSGRAM1  : origin = 0x20082800, length = 0x00000800
   CPU2TOCMMSGRAM0  : origin = 0x20084000, length = 0x00000800
   CPU2TOCMMSGRAM1  : origin = 0x20084800, length = 0x00000800
   CMTOCPU2MSGRAM0  : origin = 0x20086000, length = 0x00000800
   CMTOCPU2MSGRAM1  : origin = 0x20086800, length = 0x00000800
}

SECTIONS
{
	_start         : > CMBANK0_RESETISR,FILL=0
  .resetisr        : > CMBANK0_RESETISR,FILL=0
   .vftable         : > CMBANK0_SECTOR3,ALIGN(8) /* Application placed vector table in Flash, this shall not be collided with any other flash sectors*/
  .vtable          : > E0RAM             /* Application placed vector table in RAM*/


   .text            : >> CMBANK0_SECTOR2,ALIGN(8)
   .cinit           : > CMBANK0_SECTOR1,ALIGN(8)
   .pinit           : >> CMBANK0_SECTOR0 | CMBANK0_SECTOR1,ALIGN(8)
   .switch          : >> CMBANK0_SECTOR0 | CMBANK0_SECTOR1,ALIGN(8)
   .text            : > CMBANK0_SECTOR3, PAGE= 0, ALIGN(8) /* Here ALIGN(8) makes sure that .text section starts on a 128-bit aligned memory address*/
   //.text            : > CMBANK0_SECTOR3, PAGE= 0, ALIGN(8)
   .sysmem          : > E0RAM
   .binit 			: > CMBANK0_SECTOR1

   .stack           : > C0RAM
   .ebss            : > C0RAM
   .econst          : >> CMBANK0_SECTOR0 | CMBANK0_SECTOR1 ,ALIGN(8)
   .esysmem         : > C0RAM
   .data            : > E0RAM
   .bss             : > E0RAM
   .const           : {} LOAD = CMBANK0_SECTOR0 | CMBANK0_SECTOR1 |CMBANK0_SECTOR2 ,ALIGN(8)
   							RUN = E0RAM,
   							LOAD_START(constLoadStart),
   							LOAD_SIZE(constLoadSize),
   							LOAD_END(constLoadEnd),
   							RUN_START(constRunStart),
   							RUN_SIZE(constRunSize),
   							RUN_END(constRunEnd)

    MSGRAM_CM_TO_CPU1 : > CMTOCPU1MSGRAM0, type=NOINIT
    MSGRAM_CM_TO_CPU2 : > CMTOCPU2MSGRAM0, type=NOINIT
    MSGRAM_CPU1_TO_CM : > CPU1TOCMMSGRAM0, type=NOINIT
    MSGRAM_CPU2_TO_CM : > CPU2TOCMMSGRAM0, type=NOINIT

    .TI.ramfunc : {} LOAD = CMBANK0_SECTOR0 | CMBANK0_SECTOR1 | CMBANK0_SECTOR2 ,
                           RUN = E0RAM,
                           LOAD_START(RamfuncsLoadStart),
                           LOAD_SIZE(RamfuncsLoadSize),
                           LOAD_END(RamfuncsLoadEnd),
                           RUN_START(RamfuncsRunStart),
                           RUN_SIZE(RamfuncsRunSize),
                           RUN_END(RamfuncsRunEnd),
                           ALIGN(8)
}

/*
//===========================================================================
// End of file.
//===========================================================================
*/

4.从上面的常见问题,我们可以编程闪存,即使有 ECC 禁用,而到我们的情况下,我们是遵循同样的方法,通过禁用 ECC 和写入,我们不会面临问题写入时,我们面临的问题是,我们正在引导时。 在通过 JTAG 刷写时是否有办法禁用 ECC 默认值,以便 ECC 设置不会影响 CM 引导?

5.由于我们的问题是关于 CM 引导,需要在闪存写入期间或之后进行任何额外的设置,才能成功进行 CM 引导?

谢谢。此致、

普拉奈

Pranay,

我知道您在编程时没有看到任何 ECC 错误。  如果 ECC 未编程(或不正确)、则在发生闪存取(执行)/读取时会发生 ECC 错误。  这是你的背景下的问题。  

关于对齐： 您可以尝试对齐(16)而不是对齐(8)吗？  也许您的自定义编程器一次编程128位(但不会流式传输所有128位)-因此建议尝试对齐(16)。

谢谢。此致、

瓦姆西   

尊敬的 Vamsi：

chen chen2 说：

关于对齐： 您可以尝试对齐(16)而不是对齐(8)吗？  也许您的自定义编程器一次编程128位(但不会流式传输所有128位)-因此建议尝试对齐(16)。

1.我们在一次编程8个字节。

2.尝试使用 align (16)在写入成功但引导未发生的相同情况下结束，    下电上电后无法从 fsbl 执行代码。

chen chen2 说：

我知道您在编程时未收到任何 ECC 错误。  如果 ECC 未编程(或不正确)、则在发生闪存取(执行)/读取时会发生 ECC 错误。  这是你的背景下的问题。  [/报价]

3.所以你要说,即使写入成功, ECC 错误发生时,闪存取/读取操作,

在哪个阶段发生闪存读取？

为了进行比较、我通过 JTAG 通过 Uniflash 读取闪存中的数据是否与这次读取相同？

是否有办法禁用 ECC 默认值，以便我们不会遇到此错误？

谢谢

普拉奈

Pranay,

在这方面您还有其他问题吗？  或者我可以关闭此帖子吗？

谢谢。此致、
瓦姆西

尊敬的 Pranay：

我之所以要关闭这个职位、是因为我在过去3周没有收到您的回复。  如果您还有其他问题、请根据需要打开新帖子。

谢谢。此致、

瓦姆西