不知你所说的告警具体是什么。有些时候警告只是提醒未必是错误。


首先，这个地方的变量startaddress定义为32位是合理的也是必要的，STM8的最大寻址空间为18MB.


作为库代码，它要兼顾整个系列。


STM8支持3种寻址模式，即短寻址、长寻址和扩展寻址模式，分别对应8位地址空间、16位地址空间和整个


18MB地址空间。而且，对于8位地址寻址模式和16位寻址模式还需遵循256B和16KB地址对齐，即8位寻址模式


不是任意的8位地址空间，16位寻址模式也非任意的16位地址空间。


既然这样，具体到你提到的当前计算结果startaddress，在基于它寻址时我们需要给它指定合适的指针类型，


或说指针属性，到底是16位长模式访问  还是24位扩展模式访问，亦即代码里提到的near 还是 far属性。


不过，如果可能，真的强烈不建议你研究这个STM8芯片了。看看STM32 M0或M0+内核的芯片吧，比方STM32C0,


STM32F0,STM32G0啊，低功耗还有STM32L0啊这些。

我看你重新编辑了个帖子，这个帖子还需要吗？

xmshao 发表于 2023-10-25 11:59
不知你所说的告警具体是什么。有些时候警告只是提醒未必是错误。</p>
<p>

非常感谢你的细心回答，具体告警是

Library call(?sll32_IO_IO_a)from within a _ramfunc function以及

Library call(?add32_IO_IO_l1)from within a_ramfunc function是出现在 startaddress = staraddress + ((uint32_t)BlockNum * FLASH_BLOCK_SIZE 语句里。 尝试只有把staraddress定义为uint16_t 告警才会消除，现在是不知道这个告警对功能有没有影响，因为有时发现存到模拟EEPROM的数据会丢失，所以怀疑这个告警说明程序本身还是有问题。 另外我的意思是针对不同的型号可以用宏定义隔开，不是说不让支持大容量型

wlw129 发表于 2023-10-25 13:26
非常感谢你的细心回答，具体告警是</p>
<p>Library call(?sll32_IO_IO_a)from within a _ramfunc function ...

[md]我看到库里是有基于芯片型号做访问属性的选择，就是那个 PointerAttr；

你应该可以看到库函数在读写操作时指针前做加了个PointerAttr。

前面跟你提过，即使Near方式访问需遵循对齐，即手册中的section对齐，跨section访问必须使用FAR指针属性，即24位扩展访问模式。

另外，如果希望省事，就干脆全部使用FAR指针属性，顶多牺牲点代码效率，对功能没影响；

xmshao 发表于 2023-10-25 14:16</p>
<p>[md]我看到库里是有基于芯片型号做访问属性的选择，就是那个 PointerAttr；

[md]你好，我还是相信你们库函数的，现在这两个告警需要消除吗，或者说这里对读写EEPROM影响大吗，直接在库函数上按你说的修改吗

wlw129 发表于 2023-10-25 14:36
你好，我还是相信你们库函数的，现在这两个告警需要消除吗，或者说这里对读写EEPROM影响大吗，直接在 ...

[md]1、对于STM8而言，只有flash block编程才需要让相关代码放到RAM里执行。如果只是字节或字编程

是不涉及到RAM执行编程代码的；那么此时有关在RAM执行代码的宏就不要开启了；

2、如果的确涉及块编程，操作上跟不同IDE有点差异，在如何操作上 在flash.c文件开头介绍很详细了；

3、原则上不建议手动修改我们库代码，关于那个指针属性的选择在STM8.h文件里有清晰的选择了，你做好合适芯片选择即可；

4、这个警告到底有没有影响以你验证为主，现在我也不知道你到底用什么IDE。关于IAR的话，可能有些

警告依然存在，如果功能OK，无视即可。

xmshao 发表于 2023-10-25 15:29
1、对于STM8而言，只有flash block编程才需要让相关代码放到RAM里执行。如果只是字节或字编程</p>
<p>是不 ...

[md]好的，谢谢