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.

[参考译文] LAUNCHXL-F280049C:是否返回 DCSM GET EXE 状态? 数据值

Guru**** 2325580 points
Other Parts Discussed in Thread: C2000WARE, UNIFLASH
请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1505699/launchxl-f280049c-dcsm-get-exe-status-returns-value

器件型号:LAUNCHXL-F280049C
Thread 中讨论的其他器件:C2000WAREUNIFLASH

工具/软件:

你好、导师、

C2000ware 5.4 driverlib:获取仅执行状态(dcsm.c)返回的值与寄存器的调试视图不一致。  

看起来它应该返回 DCSM 完全存储器访问、而不是所检查的所有存储体/区域的不正确区域。 似乎不会获取闪存扇区区域、返回错误的区域消息返回状态。 GET 闪存区域(dcsm_getFlashSectorZone (sector))可能会返回完全的存储器访问、但甚至会检查!=完全访问下部 else 分支的调用矢量。 FAPI 的奇数部分无法写入组1区域2、即使该寄存器显示所有组/区域都具有仅 EXE 访问权限但设置(0x1)也是如此。 注意 FAPI 已被授予 FLSEM 区域1或区域2仍然不写入缓冲数据区域2存储体0扇区12-15。 他过去能够写入一些缓冲数据,但在通过指针访问的缓冲结构数据的数据类型更改后,他有点犹豫(停止)。

bank1 zone2是否无法写入仅授予 EXE 的数据状态? FLSEM 信标是否需要授予闪存写入器应用程序组 EXE 权限、在执行时、从执行时或从执行时执行?   

dcsm_getZone1FlashEXEStatus (dcsm_sector 扇区)

dcsm_getZone2FlashEXEStatus (dcsm_sector 扇区)

调试消息:

>> DCSM 声明 FLSEM:Zone1-> 1

>> B0_dcsm_Zone1_Sect0_Status->3
>> B0_dcsm_Zone1_sect1_Status->3
>> B0_dcsm_Zone1_Sect2_Status->3
>> B0_dcsm_Zone1_Sect3Status->3
>> B0_dcsm_Zone1_Sect4_Status->3
>> B0_dcsm_Zone1_Sect5_Status->3
>> B0_dcsm_Zone1_Sect6_Status->3
>> B0_dcsm_Zone1_Sect7_Status->3
>> B0_dcsm_Zone1_Sect8_Status->3
>> B0_dcsm_Zone1_Sect9_Status->3
>> B0_dcsm_Zone1_Sect10_Status->3
>> B0_dcsm_Zone1_Sect11_Status->3
>> B0_dcsm_Zone1_Sect12_Status->3
>> B0_dcsm_Zone1_Sect15_Status->3

>B1_dcsm_Zone2_Sect12_Status->3
>B1_dcsm_Zone2_Sect13_Status->3
>B1_dcsm_Zone2_Sect14_Status->3
>B1_dcsm_Zone2_Sect15_Status->3

>> DCSM 闪存扇区安全区域属于:
>> dcsm_memory_accessible=0、dcsm_memory_Zone1=1、
>> dcsm_memory_ZONE2=2、dcsmory_full_access=3

>> B0_CSM_ZONE1_Sect0EXE_Status-> 2
>> B0_dcsm_Zone1_Sect1Exe_Status-> 2
>> B0_dcsm_Zone1_Sect2Exe_Status-> 2
>> B0_DCSM_ZONE1_Sect3EXE_Status-> 2
>> B0_DCSM_ZONE1_Sect4EXE_Status-> 2
>> B0_dcsm_Zone1_Sect5Exe_Status-> 2
>> B0_DCSM_ZONE1_Sect6EXE_Status-> 2
>> B0_dcsm_Zone1_Sect7Exe_Status-> 2
>> B0_DCSM_ZONE1_Sect8EXE_Status-> 2
>> B0_DCSM_ZONE1_Sect9EXE_Status-> 2
>> B0_DCSM_ZONE1_Sect10EXE_Status-> 2
>> B0_dcsm_Zone1_Sect11EXE_Status-> 2
>> B0_DCSM_ZONE1_Sect12EXE_Status-> 2
>> B0_DCSM_ZONE1_Sect13EXE_Status-> 2
>> B0_DCSM_ZONE1_Sect14EXE_Status-> 2
>> B0_DCSM_ZONE1_Sect15EXE_Status-> 2

>B1_dcsm_Zone2_Sect12Exe_Status-> 2
>>B1_dcsm_Zone2_Sect13EXE_Status-> 2
>B1_dcsm_Zone2_Sect14Exe_Status-> 2
>> B1_dcsm_Zone2_Sect15Exe_Status-> 2

>> DCSM 执行状态:
>> dcsm_preprotected=0、dcsm_pretected=1、
>> dcsm_corct_zone=2、>> dcsm_full_access=3

>> dcsm_SecurityStatus->1
>> DCSM 安全状态:
>> dcsm_STATUS_SECURE=0、dcsm_STATUS_UNSECURE=1、
>> dcsm_STATUS_LOCKED=2、dcsm_STATUS_BLOCKED=3
 

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

    您好:

    如果相应安全区域被锁定、则在任何情况下都无法读取或写入 EXEONLY 存储器位置。 EXEONLY 保护存储器的唯一用法是代码执行。

    谢谢您、

    Luke

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

    您好 Luke

    FAPI 要求  授予其写入或写入的区域的执行状态。 点是 B0和 B1都显示了存储器完全访问状态(2)。 为什么 B0/B1 EXE 在信标具有 B1或 B0的完全内存访问权限时报告不正确的区域状态? 两个信标组选择都没有任何区别、FAPI 仍拒绝通过任一闪存组通过 FLSEM 声明区域信标授予执行状态来将数据写入 B1-Z2扇区。 代码仅允许一个信标在任何区域上设置的任何时间声明 FLSEM。

    uint32_t FLSEM_Status;
    /* FAPI 要求 FSEM BANK1/2区域1/2安全写入。
    *允许在闪存包装程序 FSM 寄存器中进行 Zone1写入*/
    FLSEM_Status = dcsm_claimZoneSemaphore (dcsm_FLSEM_ZONE1);
    SCIprintf (">> DCSM 声明 FLSEM:Zone1->%d\n\n"、FLSEM_Status);

    调用较低函数位移位逻辑排除返回状态可能是不正确区域以外的状态? 下面的文本仅表示 EXE (如果区域不安全)、表示应用程序对在指定扇区上执行的区域安全权限的信标声明。 这是根据 FAPI 文档、该文档要求使用区域信标来执行针对指定闪存扇区的代码(写入)。 更大的问题是 FAPI 为何无法再写入 B1-Z2扇区? 他可能在一年前将一些值写入 B1-Z2、最近决定恢复调试 FAPI、将可变电机参数存储到闪存中。  

    //! 此函数采用有效的扇区值并返回 EXE 的状态
    //! 仅为该扇区提供安全保护。
    //!
    //! 如果扇区仅受 EXE 保护、则\return 返回 dcsm_preprotected;
    //! DCSM 受保护(如果扇区不受仅 EXE 保护)、
    //! dcsm_multictor_zone (如果扇区不属于此区域)。
    //!
    //! 请注意、在实际应用程序中不应调用此函数、
    //! 只能用于调试/开发。 确保闪存数据
    //! 调用此函数(Flash_disableCache)之前禁用高速缓存。

    FAPI 需要通过区域信标授予未受保护的闪存扇区的执行(EXE)状态。 为什么 C2000ware 调用报告错误的执行状态(B0-Z1/B1-Z2)、存储体和区域都应= 1 (无保护)、而不是不正确的区域。 似乎调用用于显示 EXE=1和两个存储体和区域的 UniFlash 编程 EXE/RAM 不能清除不正确的区域消息。 FAPI 拒绝写入不安全区域 2存储体1扇区12-15。  

    >> dcsm_Zone1SecurityStatus->1
    >> dcsm_Zone2SecurityStatus->1
    >> DCSM 安全状态:
    >> dcsm_STATUS_SECURE=0、dcsm_STATUS_UNSECURE=1、
    >> dcsm_STATUS_LOCKED=2、dcsm_STATUS_BLOCKED=3

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

    切勿有意更改表3-16寄存器值、但寄存器 grapsectr 位为0xFFFFFFFF。 看起来区域被 UniFlash 反转。 表3-16应说明为默认值、因此用户明确知道寄存器位已被某些资源更改、而不仅仅是说用户不应更改它们。

    奇怪的是 、B0-Z2、B1-Z1的链路指针未编程到正确的地址。 因此、CCS 调试寄存器视图显示 B0-Z1 B0-Z2链路指针设置为0xFFFFFFFF。 即使使用 UniFlash 对所有链路指针进行重新编程、0x86000也已将地址右移1个 DWORD。

    UniFlash 和最新的 CCS v12.8 XDS110探针闪存固件地址都沿一个16位字偏移。 Make 曾在一段时间前报告过这个问题、并告知它不会造成任何问题。 为了确保构建不会受到责备、还从构建中排除了 DCSM1/2.asm 和 dcsm.cmd 文件。 从硬件寄存器加载到 DCSM 的行为有点怪异!  

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

    您好 Luke、

    从表面上看 、GEL 文件找不到区域链接指针、因为之前写入的区域链接指针从未修复。 对 GEL DCSM 模块寄存器位进行编程时假定指针地址位置不正确。 也许 TI 开发人员直接从 TRM 中获取了代码示例。 修改 DCSM GEL 段、使链接指针显示在 调试寄存器选项卡中似乎没有校正地址偏移量。 即使 MCU 复位以重新加载 DCSM 或重新启动调试固件、也没有任何帮助。 显然不是那么伟大的凝胶编程器和位烧了几天后试图找到什么是停止 FAPI 写入闪存组1。 GEL 代码似乎是应将链接指针 UniFalsh 设置0x1FFFFFFF 写入较低地址、其中刷写了 DCSM 模块的0xFFFFFFFF 错误链接指针位置、从较低的闪存地址 0x5F000开始。

    显然、链接指针在开始使用 UniFlash 并刷写链接指针(0x1FFFFFFF)之前是正常的、刷写的地址比 GEL DCSM 代码更高一个16位字。 因此、B1-Z2被锁定到 FAPI 信标应用在活动闪存存储体 B1-Z2上进行 B0写入。 GEL 代码读取从0x78000开始的链接指针并刷写到较低地址、其中"Registers"选项卡可以看到从0x5F000开始的指针。 而 CCS 调试 DCSM 寄存器选项卡绝不会显示正确的链路指针地址。  也许相同的错误也被传递到 CCS v12.8调试闪存实用程序中?

    链路指针位于闪存存储器中、但 DCSM 模块在 GEL DCSM 初始化后无法执行它们。 请查看以下代码、为 x49c MCU 提供任何建议或更正后的 GEL 文件。 提前感谢您对以下代码的任何建议或更改。

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

    似乎为所有区域设置了默认区域选择块1 (表3-18)、并且当前链接指针找到0xFFFFFFFF。 代码最后应定位全部4个区域选择块的0x1FFFFFFF 链路指针时。 显然、x49c GEL 仅查找 ZoneSelectBlock 指针、而不查找闪存存储器中确实存在的实际链接指针。 也许循环向后递增是它找到的最后一个0x00000000的链路指针?

    LinkPointer = LinkPointer << 3;  /*作为最显著的0的位31和30是无效的 LinkPointer 选项*/

    即使链路指针位于 0x5F000 = 0xFFFFFFFF、该代码也没有意义右移(>>)的结果也会正确生成0x1FFFFFFF。 偶数(<<)产生(7 FFFF FFF8)、甚至不接近 UniFlash 为所有4个链路指针值0x1FFFFFFF 设置的值。 因此、UinFlash 似乎对4个链路指针的预设地址进行了错误的编程。 对于另一个 MCU 类、而不是 x49c、起始 第一个 DCSM 链路指针地址0x5F000、可能应刷新为0x1FFFFFFF、而不是0x78000、0x78200、0x78400、0x78600、 而是 DCSM 模块链路指针地址。 闪存地址的这种更改可能会使默认区域偏移表3-18停止生效。 此外、可能会影响 x39c MCU 类、我们货架上有两个 MCU 类等待 任何修复。

     。   

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

    尊敬的 Genatco:

    对延迟的回复表示歉意。 您能否在一个回复中总结您尝试解决的当前问题? 将帮助我了解问题的当前状态。

    谢谢您、

    Luke

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

    您好 Luke、

    问题1:b0、b1 zone1 LinkPoint1将默认值0x1FFFFFFF 更改为0x0FFFFFFF 时、GEL 代码不会向定义的 OTP 存储器区域表3-18产生正确的偏移量。 会发生如上方所示的非常相同的地址向下运行、GEL DCSM 跟踪没有区别。

    问题2:表3-16使人认为两个二进制值(x.x)包含了所有扇区 B0或 B1。 而不是两个不同区域之间的单独扇区。 因此、UniFalsh 将 B0和 B1区域1:扇区0-7 0x0000和8-15 0xFFFF 进行了分频。 根据下面的地址表、这些扇区是闪存寄存器区域。 然而、即使在完全擦除后、UniFalsh 也拒绝更改 GRABSECT/RAM 和 EXEOnlySect/RAM (GrabSect、GrabRam)值0x5F000闪存寄存器区域。 该错误消息似乎可以推断 OTP 存储器已写入、但 地址范围是0x78000、0x5F000是 R/W 闪存寄存器、对吧? 除了 B0/B1链路端口1 0x0FFFFFFF 之外、还将 DCSM 安全点放在另一个 OTP 存储器偏移中、图3-18 0x1A0 (ZoneSelectBlock)。

    [C28xx_CPU1:2025年4月28日、3:32:41 PM] [info] C28xx_CPU1:GEL 输出:存储器映射初始化完成
    [DCSM 2025年4月28日、3:32:41 PM] [info] C28xx_CPU1:GEL 输出:... DCSM 初始化开始...
    [DCSM 2025年4月28日、3:32:47 PM] [info] C28xx_CPU1:GEL 输出:... DCSM 初始化完成...
    [C28xx_CPU1 2025年4月28日、3:32:49 PM] [info] C28xx_CPU1:正在执行安全操作……
    [C28xx 2025年4月28日、3:32:49 PM] [info] C28xx_CPU1:对抓取寄存器进行编程...
    [DCSM 2025年4月28日、3:32:50 PM] [info] C28xx_CPU1:GEL 输出:... DCSM 初始化开始...
    [DCSM 2025年4月28日、3:32:55 PM] [info] C28xx_CPU1:GEL 输出:... DCSM 初始化完成...
    [PLL、3:33:02 PM] [info] C28xx_CPU1:2025年4月28日 配置状态= 1。 PLL 配置成功。
    [C28xx_CPU1: 闪存编程期间发生错误。2025年4月28日、3:33:06 PM][错误] C28xx_CPU1:闪存编程期间发生错误。 地址0x00078626、FMSTAT (某些器件上为 STATCMD) 0x00000030
    [C28xx 2025年4月28日、3:33:06 PM] [错误] C28xx_CPU1:请确保尚未对正在编程的存储器位置进行编程。
    [C28xx_CPU1: 在安全操作过程中遇到2025年4月28日、3:33:06 PM][错误] C28xx_CPU1:错误。 操作已取消。

    问题3:UniFlash 可对 CMPSWD 密码进行编程并成功解锁两个区域。 对 OTPBootCtrl/Gpreg 进行编程、但 CCS 调试加载程序中的 XDS110在闪存写入验证0x81000后无法读取。 净结果 x49c 即使从 UniFlash 执行完整固件加载、也无法引导至应用程序。  

    从表面上看、如果 GEL DCSM 运行产生 图3-18中的所有偏移、更新后的 LinkPointer 1 (0x0FFFFFFF)偏移0x1A0应允许新的 OTP Zone Select 块纠正问题。 当它在偏移处找到匹配的链路指针时、会将其写入0x5F010、但如何将新指针放入寄存器中? 当前 DCSM 脚本从0x5F010读取仍保存旧链路指针0xFFFFFFFF 的数据。 UinFlash 的做法是将新链路指针写入默认的 OTP 偏移0x20、不再与数据0x5F010匹配。    

    DcsmBank0Z1Regs		DCSM BANK0 Z1 Registers	
    	B0_Z1_LINKPOINTER	0xFFFFFFFF	Zone 1 Link Pointer for flash BANK0 [Memory Mapped]	
    	Z1_OTPSECLOCK	0x00000FFF	Zone 1 OTP Secure JTAG lock [Memory Mapped]	
    	Z1_BOOTDEF_HIGH	0xFFFFFFFF	Boot definition (high 32bit) [Memory Mapped]	
    	B0_Z1_LINKPOINTERERR	0x10000000	Link Pointer Error for flash BANK0 [Memory Mapped]	
    	Z1_BOOTPIN_CONFIG	0xFFFFFFFF	Boot Pin Configuration [Memory Mapped]	
    	Z1_GPREG2	0xFFFFFFFF	Zone1 General Purpose Register-2 [Memory Mapped]	
    	Z1_BOOTDEF_LOW	0xFFFFFFFF	Boot definition (low 32bit) [Memory Mapped]	
    	Z1_CSMKEY0	0xFFFFFFFF	Zone 1 CSM Key 0 [Memory Mapped]	
    	Z1_CSMKEY1	0x47FFFFFF	Zone 1 CSM Key 1 [Memory Mapped]	
    	Z1_CSMKEY2	0xFFFFFFFF	Zone 1 CSM Key 2 [Memory Mapped]	
    	Z1_CSMKEY3	0xFFFFFFFF	Zone 1 CSM Key 3 [Memory Mapped]	
    	Z1_CR	0x0060	Zone 1 CSM Control Register [Memory Mapped]	
    	B0_Z1_GRABSECTR	Error: The function "requestMemoryRead" returned an error condition  (0x80070005)	Zone 1 Grab Flash BANK0 Sectors Register [Memory Mapped]	
    		GRAB_SECT15	11	Grab Flash Sector 15 in BANK0	
    		GRAB_SECT14	11	Grab Flash Sector 14 in BANK0	
    		GRAB_SECT13	11	Grab Flash Sector 13 in BANK0	
    		GRAB_SECT12	11	Grab Flash Sector 12 in BANK0	
    		GRAB_SECT11	11	Grab Flash Sector 11 in BANK0	
    		GRAB_SECT10	11	Grab Flash Sector 10 in BANK0	
    		GRAB_SECT9	11	Grab Flash Sector 9 in BANK0	
    		GRAB_SECT8	11	Grab Flash Sector 8 in BANK0	
    		GRAB_SECT7	00	Grab Flash Sector 7 in BANK0	
    		GRAB_SECT6	00	Grab Flash Sector 6 in BANK0	
    		GRAB_SECT5	00	Grab Flash Sector 5 in BANK0	
    		GRAB_SECT4	00	Grab Flash Sector 4 in BANK0	
    		GRAB_SECT3	00	Grab Flash Sector 3 in BANK0	
    		GRAB_SECT2	00	Grab Flash Sector 2 in BANK0	
    		GRAB_SECT1	00	Grab Flash Sector 1 in BANK0	
    		GRAB_SECT0	00	Grab Flash Sector 0 in BANK0	
    	Z1_GRABRAMR	Error: The function "requestMemoryRead" returned an error condition  (0x80070005)	Zone 1 Grab RAM Blocks Register [Memory Mapped]	
    		GRAB_RAM7	11	Grab RAM LS7	
    		GRAB_RAM6	11	Grab RAM LS6	
    		GRAB_RAM5	11	Grab RAM LS5	
    		GRAB_RAM4	11	Grab RAM LS4	
    		GRAB_RAM3	11	Grab RAM LS3	
    		GRAB_RAM2	11	Grab RAM LS2	
    		GRAB_RAM1	11	Grab RAM LS1	
    		GRAB_RAM0	11	Grab RAM LS0	
    	B0_Z1_EXEONLYSECTR	0x00000000	Zone 1 Flash BANK0 Execute_Only Sector Register  [Memory Mapped]	
    	Z1_EXEONLYRAMR	0x000000FF	Zone 1 RAM Execute_Only Block Register [Memory Mapped]	
    DcsmBank0Z2Regs		DCSM BANK0 Z2 Registers	
    	B0_Z2_LINKPOINTER	0xFFFFFFFF	Zone 2 Link Pointer for flash BANK0 [Memory Mapped]	
    	Z2_OTPSECLOCK	0x00000FFF	Zone 2 OTP Secure JTAG lock [Memory Mapped]	
    	B0_Z2_LINKPOINTERERR	0x00000000	Link Pointer Error for flash BANK0 [Memory Mapped]	
    	Z2_CSMKEY0	0xFFFFFFFF	Zone 2 CSM Key 0 [Memory Mapped]	
    	Z2_CSMKEY1	0xE3FFFFFF	Zone 2 CSM Key 1 [Memory Mapped]	
    	Z2_CSMKEY2	0xFFFFFFFF	Zone 2 CSM Key 2 [Memory Mapped]	
    	Z2_CSMKEY3	0xFFFFFFFF	Zone 2 CSM Key 3 [Memory Mapped]	
    	Z2_CR	0x0060	Zone 2 CSM Control Register [Memory Mapped]	
    	B0_Z2_GRABSECTR	0xFFFF0000	Zone 2 Grab Flash BANK0 Sectors Register [Memory Mapped]	
    	Z2_GRABRAMR	0x0000FFFF	Zone 2 Grab RAM Blocks Register [Memory Mapped]	
    	B0_Z2_EXEONLYSECTR	0x00000000	Zone 2 Flash BANK0 Execute_Only Sector Register [Memory Mapped]	
    	Z2_EXEONLYRAMR	0x000000FF	Zone 2 RAM Execute_Only Block Register [Memory Mapped]	
    DcsmBank1Z1Regs		DCSM BANK1 Z1 Registers	
    	B1_Z1_LINKPOINTER	0xFFFFFFFF	Zone 1 Link Pointer for flash BANK1 [Memory Mapped]	
    	B1_Z1_LINKPOINTERERR	0x10000000	Link Pointer Error for flash BANK1 [Memory Mapped]	
    	B1_Z1_GRABSECTR	0xFFFF0000	Zone 1 Grab Flash BANK1 Sectors Register [Memory Mapped]	
    	B1_Z1_EXEONLYSECTR	0x00000000	Zone 1 Flash BANK1 Execute_Only Sector Register [Memory Mapped]	
    DcsmBank1Z2Regs		DCSM BANK1 Z2 Registers	
    	B1_Z2_LINKPOINTER	0xFFFFFFFF	Zone 2 Link Pointer for flash BANK1 [Memory Mapped]	
    	B1_Z2_LINKPOINTERERR	0x00000000	Link Pointer Error for flash BANK1 [Memory Mapped]	
    	B1_Z2_GRABSECTR	0xFFFF0000	Zone 2 Grab Flash BANK1 Sectors Register [Memory Mapped]	
    	B1_Z2_EXEONLYSECTR	0x00000000	Zone 2 Flash BANK1 Execute_Only Sector Register [Memory Mapped]	
    

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

    问题1:

    为什么您尝试将默认链路指针值(0x1FFFFFFF)更改为(0xFFFFFFFF)? 这无法实现、因为在 OTP 中0不能更改为1。

    问题2:  

    0x5F000寄存器只是用于显示 OTP 中已编程的内容、器件复位时这些寄存器会加载 OTP 值。 不要关注这些寄存器是否已编程、因为 OTP 值至关重要。 链路端口1 0x0FFFFFFF 不是有效的链路指针、0x1FFFFFFE、0x1FFFFFFC、0x1FFFFFF8等均为有效的链路指针。

    问题3:

    此问题可能与无效的链路指针值0x0FFFFFFF 有关。 我建议阅读 技术参考手册的3.13.1.7链路指针和区域选择部分。

    谢谢您、

    Luke

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    0x0FFFFFFF 不是有效的链接指针、0x1FFFFFFE、0x1FFFFFFC、0x1FFFFFF8等均为有效的链接指针。

    Luke 我们可以使链接指针任何点30偏移区选择块和撤消坏扇区/ram 安全数据。 必须修改经过一半烘烤的 GEL 文件、以便仅支持默认偏移量0x20。 在已发布的 GEL x49c MCU 中、除了默认0x20之外、整个区域安全性从未完成支持任何其他偏移量。 该问题需要按如下所示修改 GEL 文件以生成新偏移量。 B0Z1、B1Z1是唯一获取 RAM/扇区 EXEONLY 安全性被错误更改的区域、如上面的 DCSM 寄存器捕获所示。 这是错误的误解表3-16对锁定 LSRAM 闪存扇区读取的影响  

    28位链路指针寄存器中的3个最高有效位被忽略根据图3-18、第28位和其他 MSB 位选择所需的预编程区域选择块、表3-18显示了30个偏移块、可从修改链路指针 MSB 到 LSB 中进行选择。 表3-18和图3-18表示需要将 B0Z1和 B1Z1的偏移地址重定向到另一个区域偏移。 对于两个组、只有 Z1中修改的链路指针1、而不是其他组。 因此、 在这种情况下、0x1FFF 可以设置为0xxxxx、为第28位、但始终不会再次更改并在 GEL 代码下方进行修改、从而选择正确的偏移区。 下面的 GEL 代码仅为 B0/B1 Z1选择表3-18中的块24。

    图3-18清楚地表明要修改 MSB、其中(X)表示不用考虑、从左到右读取行结束值是 TI 预编程的闪存位置 CSM 解锁密码的偏移量。 话虽如此、可能全部三个链路指针都需要具有相同的值、否则会在 DCSM 链路指针错误寄存器位的 MSB 位置发出标志。 否则、图3-18含糊不清、对任何具有数字逻辑背景的人都具有高度误导性。 有趣的是、GEL 代码永远不会更改默认链接指针偏移(0x20)、因为不会写入以选择任何其他偏移。   

    0x5F000寄存器仅用于显示 OTP 中编程的内容、

    HWREG 无法更改0x5F000和0x5F100来设置另一个区域块来选择30个偏移地址中的任何一个。 奇怪的是、GEL 文件具有 TI OTP 设置0x70000、用户 OTP 设置为0x78000。 DCSM 寄存器0x5F000、0x5F100不在 GEL 地址存储器映射中。 找到0x5F000的唯一方法是在向下钻取循环中直接引用、以选择默认区域0x1A0或默认值0x20。  

    修改后的 GEL while 循环现在会选择正确的偏移量、但 UniFlash 和 CCS 闪存实用程序不会写入0x5F000或0x5F100链路指针数据。 TRM 文本中甚至没有任何内容说明这种情况是如何发生的、还是它在 DCSM 外设中的位置发生的。

    在 B0和 B1扇区8-15之间进行了一些反射和拆分工程之后、它围绕阻塞的扇区0-7启动。 任何组位位置28上的错误标志似乎被设置为3个链路指针、需要具有相同的值、2个仍为0x1-FFFFFFF。 TRM 中没有任何内容注意到此类行为。 关于错误标志寄存器、只有一条注释说明了在位28上设置标志的原因。 由于新的 LinkPointersX 尚未在0x5F000和0x5F040寄存器中更新、原始 GEL 代码必须允许在 CCS 调试中将闪存写入未受保护的扇区。 UniFlash 实际上并未对闪存进行编程、但会继续进行详细的仿真写入 B0扇区0-7、在检查存储器时全部为0x0、8-15有数据。   

      



  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    0x0FFFFFFF 不是有效的链接指针、0x1FFFFFFE、0x1FFFFFFC、0x1FFFFFF8等均为有效的链接指针。

    Luke 我们可以使链接指针任何点30偏移区选择块和撤消坏扇区/ram 安全数据。 必须修改经过一半烘烤的 GEL 文件、以便仅支持默认偏移量0x20。 在已发布的 GEL x49c MCU 中、除了默认0x20之外、整个区域安全性从未完成支持任何其他偏移量。 该问题需要按如下所示修改 GEL 文件以生成新偏移量。 B0Z1/2、B1Z1/2是区域获取 RAM/扇区 EXEonly 安全性已发生更改、如上面的 DCSM 寄存器捕获所示。 这是错误的误解表3-16对保护闪存 R/W 扇区0-7的影响(包括区域和存储体)。  

    28位链路指针寄存器中的3个最高有效位被忽略根据图3-18、第28位和其他 MSB 位选择所需的预编程区域选择块、表3-18显示了30个偏移块、可从修改链路指针 MSB 到 LSB 中进行选择。 表3-18和图3-18表示需要将 B0Z1和 B1Z1的偏移地址重定向到另一个区域偏移。 对于两个组、只有 Z1中修改的链路指针1、而不是其他组。 因此、 在这种情况下、0x1FFF 可以设置为0xxxxx、为第28位、但始终不会再次更改并在 GEL 代码下方进行修改、从而选择正确的偏移区。 下面的 GEL 代码仅为 B0/B1 Z1选择表3-18中的块24。

    图3-18清楚地表明要修改 MSB、其中(X)表示不用考虑、从左到右读取行结束值是 TI 预编程的闪存位置 CSM 解锁密码的偏移量。 话虽如此、可能全部三个链路指针都需要具有相同的值、否则会在 DCSM 链路指针错误寄存器位的 MSB 位置发出标志。 否则、图3-18含糊不清、对任何具有数字逻辑背景的人都具有高度误导性。 有趣的是、GEL 代码永远不会更改默认链接指针偏移(0x20)、因为不会写入以选择任何其他偏移。   

    0x5F000寄存器仅用于显示 OTP 中编程的内容、

    HWREG 无法更改0x5F000和0x5F100来设置另一个区域块来选择30个偏移地址中的任何一个。 奇怪的是、GEL 文件具有 TI OTP 设置0x70000、用户 OTP 设置为0x78000。 DCSM 寄存器0x5F000、0x5F100不在 GEL 地址存储器映射中。 找到0x5F000的唯一方法是在向下钻取循环中直接引用、以选择默认区域0x1A0或默认值0x20。  

    修改后的 GEL while 循环现在会选择正确的偏移量、但 UniFlash 和 CCS 闪存实用程序不会写入0x5F000或0x5F100链路指针数据。 TRM 文本中甚至没有任何内容说明这种情况是如何发生的、还是它在 DCSM 外设中的位置发生的。

    在 B0和 B1扇区8-15之间进行了一些反射和拆分工程之后、它围绕阻塞的扇区0-7启动。 任何组位位置28上的错误标志似乎被设置为3个链路指针、需要具有相同的值、2个仍为0x1-FFFFFFF。 TRM 中没有任何内容注意到此类行为。 关于错误标志寄存器、只有一条注释说明了在位28上设置标志的原因。 由于新的 LinkPointersX 尚未在0x5F000和0x5F040寄存器中更新、原始 GEL 代码必须允许在 CCS 调试中将闪存写入未受保护的扇区。 UniFlash 实际上并未对闪存进行编程、但会继续进行详细的仿真写入 B0扇区0-7、在检查存储器时全部为0x0、8-15有数据。   

    似乎这种情况需要将所有6个链路指针设置为与在 OTP 中选择新扇区块偏移位置相同的值、以便清除所有 grab/RAM EXEonlySect 块指针中的 fubar grab 数据。

        

      



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

    更新 CSMPWDKEY 寄存器写入的问题:

    要求在虚拟读取后立即修改 x49c GEL 文件解锁 CSMPWDKEY 1-4、例如0x5F000、12、14、16和0x5F050、52、54、56。 PMF 循环 CSMPWDKEY 以解锁和写入新的区域选择块偏移。 已更新链路指针的 OTP 块指针偏移中包含 TI 预设的密码的新链路指针图3-18 默认 CSMPWDKEY 的原因不再适用于存在新 CSMPWDKEY 的链路指针块指针偏移成为新默认值的情况。

    为什么我们希望新链路指针(0x0FFFFFFF)保留默认密钥? 从表面上看、绝不会因为 OTP 中新设置的偏移包含用于解锁安全区的新密码。  

    问题在于、偏移区选择块指针的新 CSMPWDKEY 无法更新0x5F000、12、14、16或0x5F050、52、54、56。 即使是虚拟读取、也要将 PMF 添加到 GEL 中、以重写新所有者链接指针(0x0FFFFFFF)的4个密钥、指示 TI 预编程的 OTP 偏移区域。 通过 PMF 显示(0x00000000)写入地址和/或存储器映射的单个线索阻止写入 CSM++地址 (0xFFFFFFFF)。 该消息是一个关于 DCSM 外设保持锁定状态(使用默认区域 CSMPWDKEY)的位。

    编辑:从(unsigned long *)中删除 CSM (++)和(*)仍然 无法 写入寄存器 CSMPWD 密钥。 但完全读取 OTP PWD 关键值。

    奇怪的是、DCSM 外设存储器映射地址(0x0005F000)合并到一系列其他外设地址、x49c GEL 文件中。 也许会分别阻止 PMF 更新不安全的 CSMKEY 寄存器? 未设置链路指针错误标志!  

    GEL_MapAddStr (0x00040000、1、0x8000、"R|W|AS4"、0);/*外设空间*/
    GEL_MapAddStr (0x00048800、1、0x1800、"R|W|AS4"、0);/*外设空间*/
    GEL_MapAddStr (0x0004A800、1、0x13F00、"R|W|AS4"、0);/*外设空间*/
    GEL_MapAddStr (0x0005E740、1、0x18C0、"R|W|AS4"、0);/*外设空间*/

     新区域偏移虚拟读取后的 PMF 示例。 很明显、下面的示例中未显示更新的 CSMPWD 密钥。

    unsigned long *CSM;
    unsigned long *CSMPWL;
    int I;
    int tmp;
    
    
    //************************************************************
    // Unlock (unsecure) CSMPSWDSKEY B0,B1 Z1,Z2 Offsets PMF
    CSM = (unsigned long *)0x5F010;    //0x5F010/050 CSM register file 0x78010 / 0x78228
    CSMPWL = (unsigned long *)0x78028; //CSM Password location 0x783A8 (assuming defaultZone select block)
    // Read the 128-bits of the CSM password locations (PWL)
    for (I=0;I<4; I++) tmp = CSMPWL++;
    {
          // If the password locations (CSMPWL) are all = ones (0xFFFF),
          // then the zone will now be unsecure. If the password
          // is not all ones (0xFFFF), then the code below is required
          // to unsecure the CSM.
          // Write the 128-bit password to the CSMKEY registers
          // If this password matches that stored in the
          // CSLPWL then the CSM will become unsecure. If it does not
          // match, then the zone will remain secure.
          // An example password of:
          // 0x11112222333344445555666677778888 is used. 
          CSM = (unsigned long *)0xffffffff; // Register Z1_CSMKEY0 at 0x5F010
          GEL_TextOut(" UnlockPMFKeyReg_B0Z1 -%x-\n",,,,, CSM);
          CSM = (unsigned long *)0xNNFFFFFF; // Register Z1_CSMKEY1 at 0x5F012
          GEL_TextOut(" UnlockPMFKeyReg_B0Z1 -%x-\n",,,,, CSM);
          CSM = (unsigned long *)0xFFFFFFFF; // Register Z1_CSMKEY2 at 0x5F014
          GEL_TextOut(" UnlockPMFKeyReg_B0Z1 -%x-\n",,,,, CSM);
          CSM = (unsigned long *)0xFFFFFFFF; // Register Z1_CSMKEY3 at 0x5F016 
          GEL_TextOut(" UnlockPMFKeyReg_B0Z1 -%x-\n",,,,, CSM);
    }


    C28xx_CPU1:GEL 输出:链接指针的值为-0xFFFFFFFFFFFF
    C28xx_CPU1:GEL 输出:找到的链路点1的值为-0xFFFFFFF0-
    C28xx_CPU1:GEL 输出:找到的链接 Pointer1的值为-0xFFFFFFE0-
    C28xx_CPU1:GEL 输出:Found Link Pointer1的值为-0xFFFFFFC0-
    C28xx_CPU1:GEL 输出:Found Link Pointer1的值为-0xFFFFFF80-
    C28xx_CPU1:GEL Output:Found Link Pointer1的值为-0xFFFFFF00-
    C28xx_CPU1:GEL 输出:Found Link Pointer1的值为-0xFFFFFE00-
    C28xx_CPU1:GEL 输出:Found Link Pointer1的值为-0xFFFFFC00-
    C28xx_CPU1:GEL Output:Found Link Pointer1的值为-0xFFFFF800-
    C28xx_CPU1:GEL 输出:Found Link Pointer1的值为-0xFFFFF000-
    C28xx_CPU1:GEL 输出:Found Link Pointer1的值为-0xFFFFE000-
    C28xx_CPU1:GEL 输出:Found Link Pointer1的值为-0xFFFFC000-
    C28xx_CPU1:GEL 输出:Found Link Pointer1的值为-0xFFFF8000-
    C28xx_CPU1:GEL 输出:Found Link Pointer1的值为-0xFFFF0000-
    C28xx_CPU1:GEL 输出:Found Link Pointer1的值为-0xFFFE0000-
    C28xx_CPU1:GEL 输出:Found Link Pointer1的值为-0xFFFC0000-
    C28xx_CPU1:GEL 输出:Found Link Pointer1的值为-0xFFF80000-
    C28xx_CPU1:GEL 输出:找到的 Link Pointer1的值为-0xFFF00000-
    C28xx_CPU1:GEL 输出:找到的链接 Pointer1的值为-0xFFE00000-
    C28xx_CPU1:GEL 输出:Found Link Pointer1的值为-0xFFC00000-
    C28xx_CPU1:GEL 输出:Found Link Pointer1的值为-0xFF800000-
    C28xx_CPU1:GEL Output:Found Link Pointer1的值为-0xFF000000-
    C28xx_CPU1:GEL 输出:找到的链接 Pointer1的值为-0xFE000000-
    C28xx_CPU1:GEL 输出:找到的链接 Pointer1的值为-0xF000000
    C28xx_CPU1:GEL 输出:找到的链接 Pointer1的值为-0xF8000000-
    C28xx_CPU1:GEL 输出:找到的链接 Pointer1的值为-0xF0000000 -
    C28xx_CPU1:GEL 输出:找到的链路点1的值为-0xE0000000-
    C28xx_CPU1:GEL 输出:找到的链接 Pointer1的值为-0xC0000000-
    C28xx_CPU1:GEL 输出:所找到链接 Pointer1的值为-0x80000000-
    C28xx_CPU1:GEL 输出:Found Link Pointer1的值为-0x00000000-
    C28xx_CPU1:GEL 输出:ZoneSelectBlock Pointer1的值为-0x00078420-

    C28xx_CPU1:GEL 输出:DummyReadsZoneSelectBlockPoint1 -0x00078422-
    C28xx_CPU1:GEL 输出:DummyReadsZoneSelectBlockPoint1 -0x00078424-
    C28xx_CPU1:GEL 输出:DummyReadsZoneSelectBlockPoint1 -0x00078426-
    C28xx_CPU1:GEL 输出:DummyReadsZoneSelectBlockPoint1 -0x00078428-
    C28xx_CPU1:GEL 输出:DummyReadsZoneSelectBlockPoint1 -0x0007842A-
    C28xx_CPU1:GEL 输出:DummyReadsZoneSelectBlockPoint1 -0x0007842C-
    C28xx_CPU1:GEL 输出:DummyReadsZoneSelectBlockPoint1 -0x0007842E-
    C28xx_CPU1:GEL 输出:DummyReadsZoneSelectBlockPoint1 -0x00078430-
    C28xx_CPU1:GEL 输出:UnlockDefaultPMFKeyReg_b0Z1 -0xFFFFFFFFFF-
    C28xx_CPU1:GEL 输出:UnlockDefaultDefaultPMFKeyReg_b0Z1 -0x47FFFFFF-
    C28xx_CPU1:GEL 输出:UnlockDefaultPMFKeyReg_b0Z1 -0xFFFFFFFFFF-
    C28xx_CPU1:GEL 输出:UnlockDefaultPMFKeyReg_b0Z1 -0xFFFFFFFFFF-

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

    尊敬的 Genatco:

    我对问题的理解是、如果链接指针已更新、GEL 文件不会自动更新其 CSMKEY 值以解锁 DCSM。 这是正确的吗? 如果是、我将了解是否可以将此功能添加到 GEL 文件中。

    谢谢您、

    Luke

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

    您好 Luke、

    也许情况更糟。 在设置新偏移量和新密钥之前、下面修改后的 GEL 首先解锁原始密钥。 仍然不会将 DCSM 寄存器链路指针全部更新为0x0FFFFFF。 似乎 MSB 位28被设置为0部分是因为当只有两个指针发生更改(每组一个、上面显示的链接指针错误)时没有设置链路错误标志。 想知道清除几个 LSB 位 DCSM 寄存器(0x5F000、0x5F050)是否会接受更新后的偏移链路指针? 奇怪的是、这两个地址都保持为0xFFFFFFFF。

    您可以使用下面修改后的 GEL 代码进行尝试。 它允许 MCU 将固件写入两个区域中均未受保护的其他扇区。 没有时间恢复到 x49c、但想解锁扇区0-7组0-1。 已针对 GEL 和0x1A0中当前设置的最后一个偏移0x1F0进行了测试、这两个偏移都不起作用  

    e2e.ti.com/.../2335.f280049c.zip 

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

    尊敬的 Genatco:

    每个组有3个链路指针实例。 所有三个链接指针都应 一起修改、而不仅仅是一个。

    0x5F000地址空间中的链路指针寄存器将不会反映 OTP 链路指针的 MSB 位、因为预计这些位不会被修改。 这可能是您看到所有 Fs 的原因、或者因为您修改了链接指针的 MSB、而不是 LSB。

    我认为您应该使用正确修改的链接指针重新开始新器件。 如果您使用的是非法的链接指针值、我希望 DCSM 不能正常运行。

    谢谢您、

    Luke

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    应 同时修改所有三个链接指针、而不仅仅是一个。

    您好 Luke、

    组和区域链路指针 MSB 已更改、现在全部匹配。 看似如果我们分别修改 LSB、DCSM 将在 LSB 发生变化时更新0x5F000和0x5F050、并显示 MSB 清除位。 由于 DCSM 现在会忽略清除的 MSB 位并通过图3-18将新的偏移地址置为有效、因此是一个逻辑扣减。 但尚未在测试台上下一次就测试过这一想法。  感谢您的大力支持:-)