Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(CMSIS): Adding mallinfo function and reworking Cordio memory management. #1179

Open
wants to merge 11 commits into
base: main
Choose a base branch
from

Conversation

kevin-gillespie
Copy link
Contributor

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.

@kevin-gillespie kevin-gillespie added the WIP work in progress label Sep 18, 2024
@github-actions github-actions bot added MAX32655 Related to the MAX32655 (ME17) MAX32665 Related to the MAX32665 (ME14) MAX32690 Related to the MAX32690 (ME18) labels Sep 18, 2024
Need to call this multiple times to allow us to calculate the size
requirements before requesting the heap memory.
This is a significant API change. We need to call WsfHeapAlloc with
the required size before calling WsfHeapGetFreeStartAddress. This
will allow us to do dynamic memory allocation, instead of allocating
a large block of memory on initialization.
@github-actions github-actions bot added the BLE Related to Bluetooth label Sep 18, 2024
Comment on lines 114 to 117
void LlInitRunTimeCfg(const LlRtCfg_t *pCfg)
{
WSF_ASSERT(pLctrRtCfg == NULL);
// WSF_ASSERT(pLctrRtCfg == NULL);
WSF_ASSERT(pCfg);
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the intention to entirely remove this commented line?

It makes sense to me that pLctrRtCfg may possibly be empty in this context -- given that it is not read and later assigned to pCfg.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes we need to remove this check. The problem is that we will get an assertion if this function is called twice. We need to call this twice to calculate the length of dynamic memory needed.

Comment on lines 52 to +54
void BbInitRunTimeCfg(const BbRtCfg_t *pCfg)
{
WSF_ASSERT(pBbRtCfg == NULL);
// WSF_ASSERT(pBbRtCfg == NULL);
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ditto. Similar observation for pBbRtCfg in BbInitRunTimeCfg().

@kevin-gillespie
Copy link
Contributor Author

@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
Copy link

crsz20 commented Sep 20, 2024

@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?

@kevin-gillespie
Copy link
Contributor Author

@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?

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

@crsz20
Copy link

crsz20 commented Sep 20, 2024

/clang-format-run

* \return Memory used.
*/
/*************************************************************************************************/
uint32_t LlInitMemConfig(LlInitRtCfg_t *pCfg)
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I decided to name this function MemConfig because I see it is doing two things:

  • Setting run-time configurations
  • Computing the amount of heap memory used

Though, perhaps I could have simply named it LlInitSetRtCfg(). I think this is preferable. Let me know what you think.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like LlInitSetRtCfg(). Take the guts of 322 to 334 and replace those lines with a call to LlInitSetRtCfg().

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Observation

I noticed in LlInit() that the following lines are performed after calling both LlInitSetBbRtCfg() and LlInitSetLlRtCfg().

pCfg->pFreeMem += memUsed;
pCfg->freeMemAvail -= memUsed;

In the updated examples, on the other hand, these are performed only once after LlInitSetBbRtCfg() and omitted after LlInitSetLlRtCfg(). Such as, here.

Conclusion

I am willing to bet that the examples needed that additional increment/decrement of memUsed. I will go ahead and add it to our new function LlInitSetRtCfg(). Is that correct?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it's significant, but it can't hurt. I'm pretty sure that llCfg structure is only used to pass the initialization paramters. I don't think it's used once it returns from the init function.

@crsz20
Copy link

crsz20 commented Sep 24, 2024

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.

@kevin-gillespie
Copy link
Contributor Author

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.

@crsz20
Copy link

crsz20 commented Sep 24, 2024

Seems to be failing at the checksum verification.

@kevin-gillespie
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
BLE Related to Bluetooth MAX32655 Related to the MAX32655 (ME17) MAX32665 Related to the MAX32665 (ME14) MAX32690 Related to the MAX32690 (ME18) WIP work in progress
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants