TMS320F28377S: FLASH API指定单独flash和ram区域，程序正常运行，但非API代码更改后生成的Flash28_API 部分内容可能变更

WEI ZHANG

开发汽车UDS刷写，基于安全考虑，需将FLASH API部分独立为dirver文件，后续由can下发后使用，通过指定单独flash和ram区域整个功能已经实现。

目前问题：整个工程可能因为更改其他功能导致生成的driver文件有细微变更，查看map文件Flash28_API占用内存的大小没有变化，仅此部分对应flash内容就是有区别，导致不同版本boot文件对应dirver文件不一致，不利于项目管理。

项目用了28335和28377两种芯片，都有出现类似现象，下面已28377工程举例说明。

最后分析的表象原因可能是优化等级会影响，ram运行大小变化会影响，但是api部分代码不是固定的吗，怎样才能做到工程变更不影响driver文件生成。

下图为前后map文件Flash28_API对比：

下图是前后dirver.mot16文件对比：

dirver文件区别涉及以下三部分：

Read.obj (.text:_Fapi_loopRegionForValue)

0x99B5(39349) 0x9117(37143)

: FlashStateMachine.obj (.text:_Fapi_setupSectorsForWrite)

0x9961(39265) 0x9119(37145)

0x9998(39320) 0x9190(37264)

: Utilities.obj (.text:_Fapi_scaleCycleValues)

0x99B5(39349) 0x9117(37143)

25 天前

0 Eirwen 24 天前

TI__Mastermind 35945 points

已经收到了您的案例，调查需要些时间，感谢您的耐心等待。

0 Alice 23 天前回复 Eirwen

TI__Mastermind 45550 points

您好，

请问如下对于您问题的理解正确吗？

1. 您使用 Flash API 库创建了一个“flash driver”抽象层，该抽象层在所有版本的应用程序中都位于固定的内存地址。Flash API 库被加载到闪存中，但从 RAM 运行。

2. 作为开发过程的一部分，“flash driver”抽象层的文件可能会被修改。

3. 当“flash driver”文件发生更改时，即使它以相同的方式在所有版本的应用程序中链接，也会导致关联的 Flash API 库二进制代码发生更改。即使项目的所有其他方面（优化等）保持不变，这也仍然成立。

由于没有Flash API 源码或库，请考虑下面人为构造的示例来源。

extern int user_global;

int library_function()
{
    return user_global;
}

user_global 的地址的一部分会在为 library_function 生成的至少一条指令中被编码。这些位的值会随着 user_global 的位置变化而变化。user_global 的位置与 library_function 的位置无关。最终的决定是在链接时做出的。

在 flash API 源代码中很可能发生类似的情况。请检查。