Flash size of BLE Applications

RE: Flash size of BLE Applications

H.Marske — Tue, 25 Mar 2025 14:16:27 GMT

Hi,

Sorry i get back to you so late but we had to wait a long time before the Hardware arrived.

I fixed the problem with your help as it was indeed the same problem with the swapped quartzes.

Thanks for your help!

Greetings Hendrik

RE: Flash size of BLE Applications

H.Marske — Fri, 28 Feb 2025 15:29:59 GMT

oh my... I know the issue then. We already had this issue as the whole chip usually runs from the external oscillator per default. In the initial HW-Design the LF and HF Oscillators were swapped around. We almost debugged for 2 whole weeks as we could not figure out what the problem was.

I will get it checked early next week and report then.

RE: Flash size of BLE Applications

Einar Thorsrud — Fri, 28 Feb 2025 15:26:10 GMT

I see. The assert indicate that the HFXO is not running when it should. It oculd be that the HF clock does not start at all, or that it starts too slowy (both would be a hardware issue). Have you successfully run any readio applications on this board or tested that the HFXO works?

RE: Flash size of BLE Applications

H.Marske — Fri, 28 Feb 2025 15:03:28 GMT

i am using nrf Connect SDK v2.7 wich is the same for the toolchain

RE: Flash size of BLE Applications

Einar Thorsrud — Fri, 28 Feb 2025 15:01:25 GMT

Thanks, that is what I was looking for. However, I forgot to ask which SDK version you are using?

RE: Flash size of BLE Applications

H.Marske — Fri, 28 Feb 2025 14:56:08 GMT

on the left you can see the file and line parameter

Thanks four your help!

RE: Flash size of BLE Applications

Einar Thorsrud — Fri, 28 Feb 2025 14:20:26 GMT

Hi,

This shows an MPSL assert. As logging is diffucult, can you debug in m_assert_handler() and check the file and line? (If it is easier you can allo make a custom mpsl_assert_handle() function and check there). I can look up the MPSL assert information to see if it gives any pointers.

RE: Flash size of BLE Applications

H.Marske — Fri, 28 Feb 2025 13:50:52 GMT

Enabeling loggin would overflow flash by 29080B and RAM by 3400B, so there is no point in enabeling this.

I have attached the stacktrace on failure. I would read it as i try calling the mpsl workqueue out of an ISR but i am not. I call this

The reason-Parameter is 4

It fails after starting the scan with bt_le_scan_start but before i stop it.
I can post the start-scanning-code as well as the stopping if it helps

RE: Flash size of BLE Applications

Einar Thorsrud — Fri, 28 Feb 2025 13:18:19 GMT

Hi,

The default configurations typically have some headroom with regards to buffer sizes etc which affect RAM, and also include support for features you may not need, which affect both flash and RAM usage. I see you are able to fit th eapplication, though just barely. With optimizations, I exect you should have a bit more headroom. I do not have an example that does exactly what you describe, but you can refer to the prj_minimal.conf here which gives a good idea (though this is for a Bluetooth peripheral device). Zephyr also has a sample with a prj_minimal.conf for a central. There is also documentation on Memory footprint optimization that is worth exploring.

As you are able to build the project, I do not believe the issue you are seeing when testing is due to lack of memory. The linker was able to place everything in RAM, includign all buffers etc. But to know more about why you see a crash when starting scannng we need to debug (first I would start by olbserving the log if you have logging enabled to see if there is a fault).