analogdevicesinc
feat(CMSIS): Adding mallinfo function and reworking Cordio memory management.
Description
Adding mallinfo function to give us information on how much heap space is being used and how much is available. Reworking the Cordio memory management so we don't have to request an arbitrarily large block of memory on initialization.
Checklist Before Requesting Review
- [ ] PR Title follows correct guidelines.
- [ ] Description of changes and all other relevant information.
@crsz20 I was just thinking, it would be good to add a LL function for the size calculation. We're copying a lot of code that could be consolidated.
@crsz20 I was just thinking, it would be good to add a LL function for the size calculation. We're copying a lot of code that could be consolidated.
Which part do you think could be consolidated? In the heap.c files?
@crsz20 I was just thinking, it would be good to add a LL function for the size calculation. We're copying a lot of code that could be consolidated.
Which part do you think could be consolidated? In the
heap.cfiles?
Lines 127 - 133 in the file below. We could add a function with the same parameters as LlInit() that returns the memory requirement.
https://github.com/analogdevicesinc/msdk/pull/1179/files#diff-7c5e05044eb55068c970128b55bc1b31c278e44f82c0d2325b275d4606af3d9fR127
Found a bug in the in BLE4_ctr example on ME17 that seems to date back to the following commit:
- "Reworking HeapAlloc usage" (1a2400e)
The BLE_datc and some other examples seem to run fine, however. I back-traced the error to PalCfgLoadData() in main.c > palCfgLoadBdAddress() > MXC_SYS_GetUSN() failing to an assertion trap in pal_cfg.c.
I am not sure how this may be dependent on the recent changes to the heap memory management.
Yes it sounds unrelated. I'm not sure why it would only fail on this example. That same procedure is done in most of the examples to get the Bluetooth address. Can you step through the procedure to see how it's failing?
We've seen this before on pre-production parts where the USN isn't programmed properly. This would be a chip specific error that we would always see, not a software error.
Seems to be failing at the checksum verification.
This is a common problem with the pre-production parts. Please try a different board to see if we have the same problem.
The USN bug seems to be unrelated and is being resolved in a separate PR. Will proceed to update the rest of the examples.
In BLE demos, is it necessary to add a CMD to display the contents of struct mallinfo?
In BLE demos, is it necessary to add a CMD to display the contents of struct mallinfo?
No, I don't think so. The memory management is handled behind the scenes.