We have good working code for the PAN1740 incorporating BASS, DISS, and a custom profile CUSTS1.
We have recently added support for SUOTA and now have an out of memory error at run time.
Program Size: Code=23964 RO-data=3032 RW-data=1096 ZI-data=8156
We're a little disappointed that such a small app (our customer profile is fairly simple) is already running up against resource constraints.
Can you advise on best steps to take to resolve this situation?
The compiler is set to "C99 mode" and optimise Level 3 (-O3) - would anything else here help?
Can we manually change the heap/stack etc. in a safe way? How?
我们可以删除任何调试stuf吗f?
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.
Looking a bit deeper, in the map file I find
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.
I have an external processor and I send messages back and forth via a GTL.
At initialization time there is a message containing the bondDB sent that is just over 100 bytes.
If EXCLUDE_DLG_SPOTAR = (1) and SPOTAR is excluded, then the GTL init message is correctly received.
if EXCLUDE_DLG_SPOTAR = (0) and SPOTAR is included, then the GTL init message is not received, and we get an out of memory error. This takes the form of a call to
void wrap_platform_reset(uint32_t error)with error = 0xf2f2f2f2Any thoughts?
Thanks,
Paul.
Hi pvmellor,
Regarding your first question, since you have a total ROM size of 27.43kB then i dont see any issue in downloading the code into the 580, with this code size you should be able to download code into the device. And also you should have additional room for extra code in this. The 0xF2F2F2F2 is a memory allocation failure message, this is invoked when the device is running out of heap, i dont see any clear relation between the SPOTAR profile and the message with the bonding data that you send from the external device, apparently there is somekind of a memory leak that causes this. Anyway you can try to increase the heap that stores the messages send to the kernel by defining the MSG_HEAP_SZ in the da1458x_config_advanced.h file and overide the default value. If you think that the default 32K scatter file isn't enough for the implementation that you will have and you would like to enlarge the default mapping then there are tips that can be applied and enlarge the image produced, a few of them can be found in this posthttps://support.dialog-semiconductor.com/how-build-program-code-larger-32kb. There is no additional optimization over the -O3, if you dont use debugging features like the implementation of the UART debug that code should not be involved in your image since you are using the -O3 optimization. Regarding the venners, you cannot just ommit them, you will have to place the code and execute from address zero instead of 0x20000000 in order to avoid the long jumps between the ROM code and the sysram, i order to do so you will have to change the sysram base address in the scatter file and instead of using the 0x20000000 use the 0x0 address, for example in the LR_IROM1 instead of 0x20000000 0x160 you should change that to LR_IROM 0x0 0x160 (this applies to all the memory regions that use the 0x20000000 as a base address), this will save you about 1.5kB. Just to be clear on this, the above recommendations are just tips, if you decide to go through those suggestions and try them out you should be aware that are not tested, since this is something that is application depended, additonally since you are extending the size of the image you would be able to use deep sleep. I dont get the last question though, since you are booting the image from an external MCU what you would like to monitor ?
Thanks MT_dialog
Thanks for getting back, with 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.
However I still do not feel we have fully understood the problem and would like to follow up on your suggestion to check for memory leaks. I wonder if you could help me understand how to do this best? If a message is not consumed (by accident) is there a way to tell? Can we check or monitor the heap size or any instrumentation on the number of messages processed, bytes used etc?
Thanks,
Paul.
Hi pvmellor,
There is no standard way to trace where the memory leak is, you will have to check the code, There is also a utility that can help you monitor the heap size, but only while you are in debug mode, so #define the CFG_LOG_MEM_USAGE build the code and while the device runs, stop execution and then you can open the console in keil and then type disp_memlog() (+enter) and then the various heaps and the corresponding sizes will apper to the command window.
Thanks MT_dialog