TLE9893是否支持在FLASH1上运行代码来擦除和编程FLASH1？

是的，TLE9893 支持在 FLASH1 上运行代码来擦除和编程 FLASH1 本身，并且通常不需要将自编程代码复制到 RAM 中执行。这得益于 TLE9893 的 双组独立 Flash 架构（FLASH1 和 FLASH2） 和 英飞凌特定的 NVM-PROG_UCODE 机制。

关键点解释：

1. 
   

   双组独立 Flash (FLASH1 & FLASH2):

   
   
   
   
   • TLE9893 内部有两组物理上独立的 Flash 存储体：通常称为 FLASH1 和 FLASH2。
   
   
   • 它们有独立的控制器、地址空间和访问总线。
   
   
   • 这是实现你描述的功能的最核心硬件基础。
   
   
   
   


2. 
   

   NVM-PROG_UCODE 机制：

   
   
   
   
   • 这不是用户应用代码，而是英飞凌固化在芯片 ROM 或特殊 Flash 区域中的一段低级 Flash 编程驱动程序（通常称为 NVM Programming UCode）。
   
   
   • 这段代码是经过英飞凌精心设计和验证的，其唯一职责就是执行 Flash 的擦除和编程操作。
   
   
   • 它与用户应用代码是分离的。
   
   
   
   


3. 
   

   操作流程（在 FLASH1 上运行 APP 代码，要擦写 FLASH1 的一个 Page）：

   
   
   
   
   • 用户代码（运行于 FLASH1）： 你的应用程序运行在 FLASH1 上。当它需要擦除或编程 FLASH1 的某个扇区（比如最后一页）时，它会调用英飞凌提供的 Flash 驱动 API (例如 FLS_EraseSector, FLS_Write 等)。
   
   
   • API 调用： 这些 API 函数（虽然代码在 FLASH1）主要作用是设置好目标地址、数据缓冲区指针、操作类型等参数。
   
   
   • 触发 NVM-PROG_UCODE： 关键的 API 函数（如 FLS_EraseSector 的执行部分）最终会触发一个机制（例如，设置特定寄存器、执行特定指令序列），使得芯片硬件暂停 FLASH1 的访问，并跳转执行 ROM 或特定 Flash 区域中的 NVM-PROG_UCODE。
   
   
   • NVM-PROG_UCODE 执行（关键）： 这段 NVM-PROG_UCODE 是由芯片制造商固化好的，它很可能运行在与当前操作目标 Flash 组无关的位置：
     
     
     
     • 它可能固化在 ROM 中 -> 与 FLASH1/2 都独立。
     
     
     • 它可能固化在专用的 NVM-PROG_UCODE Flash Segment（可能在 FLASH2 的一部分） -> 与正在被擦写的 FLASH1 物理独立。
     
     
   
   
   • 独立 Flash 组操作： 执行擦除/编程操作的硬件逻辑是直接操作目标 Flash 组（这里是 FLASH1）。因为 NVM-PROG_UCODE 本身并不运行在 FLASH1 上，而是运行在 ROM 或 FLASH2 上，所以：
     
     
     
     • CPU 取指： CPU 从 ROM 或 FLASH2 读取 NVM-PROG_UCODE 指令。
     
     
     • 数据访问： NVM-PROG_UCODE 读写的数据缓冲区（用户数据）通常位于 RAM 中。
     
     
     • 目标 Flash 操作： 硬件直接对 FLASH1 进行擦除/编程。
     
     
     • 关键： 对 FLASH1 的擦除/编程操作不会阻塞 CPU 从 ROM 或 FLASH2 读取指令（NVM-PROG_UCODE），因为它们是不同的物理存储体和总线。
     
     
   
   
   • 完成与返回： NVM-PROG_UCODE 完成操作后，会通过状态标志或中断通知系统，然后控制权返回给最初在 FLASH1 上发起调用的用户 API 函数（此时 FLASH1 的访问已恢复）。API 函数检查状态并返回给用户应用代码。
   
   
   
   

为什么不需要把代码复制到 RAM？

• 分离的执行源： 执行 Flash 操作的核心代码（NVM-PROG_UCODE）本身就不在目标 Flash 组（FLASH1）上运行。它运行在独立的 ROM 或 FLASH2 上。因此，即使 FLASH1 正在被擦除或编程，CPU 仍然可以顺畅地从 ROM/FLASH2 读取指令继续执行 NVM-PROG_UCODE。


• 硬件设计保障： 英飞凌在设计 NVM-PROG_UCODE 和 Flash 控制器时，确保了其执行路径不依赖于目标 Flash 组的内容。操作是通过专门的硬件寄存器/状态机控制的。


• 用户代码的角色： 你在 FLASH1 上写的 Flash 驱动 API 调用代码，其作用只是设置参数和触发真正的底层操作（NVM-PROG_UCODE）。一旦触发完成，这段 API 代码就暂时不需要执行了。触发后 CPU 跳转去执行 ROM/FLASH2 中的 UCode，FLASH1 在操作期间暂时不可读也没关系。

总结:

1. 支持： TLE9893 支持在 FLASH1 上运行代码来擦除和编程 FLASH1。


2. 机制： 核心是利用 独立双组 Flash (FLASH1 & FLASH2) 和固化在 独立位置 (ROM 或 FLASH2) 的 NVM-PROG_UCODE。


3. 无需RAM副本： 正是因为执行擦除/编程操作的 NVM-PROG_UCODE 本身不运行在目标 Flash 组（FLASH1）上，而是运行在独立的 ROM 或 FLASH2 上，所以不需要将这段代码复制到 RAM 中执行。它在 ROM/FLASH2 上可以安全地执行，即使目标 Flash 组正在进行写入操作。


4. 用户代码： 用户只需要调用英飞凌提供的标准 Flash API 即可。这些 API 负责参数传递和触发底层 UCode，它们的代码放在 FLASH1 中是安全的。

因此，在 NVM-PROG_UCODE 方案中，利用芯片的硬件架构和固化的 UCode，你不需要将 Flash 操作代码复制到 RAM 来擦写 FLASH1。

举报