We have good working code for the PAN1740 incorporating BASS, DISS, and a custom profile CUSTS1.
我们最近添加了对SUOTA的支持，现在运行时出现内存不足错误。
程序大小：代码=23964 RO数据=3032 RW数据=1096 ZI数据=8156
我们有点失望，这样一个小的应用程序（我们的客户资料相当简单）已经在运行的资源限制。
你能就解决这种情况的最佳措施提出建议吗？
The compiler is set to "C99 mode" and optimise Level 3 (-O3) - would anything else here help?
我们能否以安全的方式手动更改堆/堆栈等？怎么用？
我们能删除任何调试内容吗？
What are the veneers? They seem to take up a fair bit of room.
Can we move stuff into different RAM areas? We boot the PAN from code held remotely on a controller MCU via SPI. How do we monitor the sizes of these? What's already in them?
I'm sure there are lots of other things...
Thanks,
Paul.
设备：
再深入一点，在我找到的地图文件里
Total ROM Size (Code + RO Data + RW Data) 28092 ( 27.43kB)
So I'm thinking this should fit as it is under the 32k limit.
我有一个外部处理器，我通过GTL来回发送消息。
At initialization time there is a message containing the bondDB sent that is just over 100 bytes.
如果EXCLUDE \u DLG \u SPOTAR=（1）并且SPOTAR被排除，则正确接收GTL init消息。
如果EXCLUDE DLG_SPOTAR=（0）并且包含SPOTAR，则不会收到GTL init消息，并且会出现内存不足错误。它的形式是呼叫
void wrap_platform_reset(uint32_t error)错误=0xF2F2F2有什么想法吗？
Thanks,
Paul.
嗨，梅勒，
关于你的第一个问题，因为你有一个27.43kB的总ROM大小那么我没有看到任何问题下载到580的代码，与这个代码大小你应该能够下载到设备的代码。而且你应该有额外的空间来存放额外的代码。0xf2f2是一条内存分配失败消息，当设备堆用完时调用它，我看不到SPOTAR配置文件和消息与从外部设备发送的绑定数据之间有任何明确的关系，显然是某种内存泄漏导致了这种情况。无论如何，您可以尝试通过在da1458x\u config\u advanced.h文件中定义MSG\u heap\u SZ并覆盖默认值来增加存储发送到内核的消息的堆。如果你认为默认的32K散点文件不足以实现你将有，你想扩大默认映射，然后有一些技巧，可以应用和扩大产生的图像，其中一些可以在这篇文章中找到https://support.dialog-semiconductor.com/how-build-program-code-larger-32kb. 在-O3上没有额外的优化，如果您不使用调试特性（如UART调试的实现），那么代码不应该包含在您的映像中，因为您使用的是-O3优化。关于Venner，您不能只对它们进行操作，您将不得不放置代码并从地址0而不是0x20000000执行，为了避免ROM代码和系统内存之间的长跳转，我命令您这样做，您将不得不更改散点文件中的系统内存基地址，而不是使用0x20000000使用0x0地址，例如，在LR\u IROM1而不是0x20000000 0x160中，您应该将其更改为LR\u IROM 0x0 0x160（这适用于所有使用0x20000000作为基址的内存区域），这将为您节省大约1.5kB。为了明确这一点，上面的建议只是提示，如果你决定通过这些建议，并尝试他们，你应该知道，没有测试，因为这是一些应用程序依赖，另外，因为你是扩大图像的大小，你可以使用深度睡眠。我没有得到最后一个问题，虽然，因为你是从一个外部启动MCU的图像你想监视什么？
Thanks MT_dialog
谢谢你回来，和我一起some very useful information.
Yes I am sure now it is a heap issue. With SPOTAR included, if I reduce the size of the first GTL message I send to the PAN1740 to 1 byte, then the message is received ok, if I increase it back to its 100 bytes, then I get an out of memory error. With SPOTAR excluded I do not have this problem. I do note from "UM-B-011 Figure 2 memory map" that SPOTAR patches are held in the retention ram right next to the MSG Heap. So I am wondering if this is the source of the problem. It also seems that the heap sizes are strictly calculated - but do they include additional user-defined GTL messages? Anyway, we have had to remove SPOTAR and implement our own characteristics in our customer service for firmware update.
不过，我仍然觉得我们还没有完全理解这个问题，并希望跟进您的建议，检查内存泄漏。我想知道你能不能帮我弄明白如何做到最好？如果一条信息没有被（偶然）消费掉，有没有办法告诉你？我们是否可以检查或监视堆大小或处理的消息数、使用的字节数等任何工具？
Thanks,
Paul.
嗨，梅勒，
没有标准的方法来跟踪内存泄漏的位置，您必须检查代码，还有一个实用程序可以帮助您监视堆大小，但只能在调试模式下使用，因此#定义CFGŠLOGŠMEMŠu用法构建代码，并在设备运行时，停止执行，然后您可以在keil中打开控制台，然后键入disp\u memlog（）（+enter），然后各种堆和相应的大小将出现在命令窗口中。
Thanks MT_dialog