how to isolate the unwanted bluetooth signal during debug?

RE: how to isolate the unwanted bluetooth signal during debug?

zzzh — Wed, 05 Dec 2018 01:47:40 GMT

Got it.

Thank you so much for the help, Terje.

Regards.

RE: how to isolate the unwanted bluetooth signal during debug?

tesc — Tue, 04 Dec 2018 16:36:57 GMT

Hi,

Then you should have a look at the id, pc and info that you got when breaking in app_error_fault_handler for the first time, as that will point you towards the error.

You may have some luck with setting up Monitor Mode Debugging with the nRF5 SDK for Mesh, but as far as I know this is not something we have tried. (We have only used it with the nRF5 SDK.) If you can manage with only stopping once when debugging then I suggest that you work within that limitation.

Regards,
Terje

RE: how to isolate the unwanted bluetooth signal during debug?

zzzh — Tue, 04 Dec 2018 16:09:30 GMT

Hi, Terje,

Yeah, I do have breakpoints in app_error_fault_handler, though, there are too many NRF_MESH_ASSERT..

So SoftDevice make that happen? how you Nordic guys do debugging in such situation?

Can Real-time debugging solve this issue? if yes, how to set breakpoints in Thread mode or lower priority interrupts?

Thanks & Regards

RE: how to isolate the unwanted bluetooth signal during debug?

tesc — Tue, 04 Dec 2018 15:39:20 GMT

Hi,

Other signals (including other bluetooth signals) does not lead to the behavior that you see.

Ending up in sleep_forever() means you have hit an assert. You should have gotten a log message telling what the error is, if you have enabled logging. Another way to find out what exactly the assert is is to put a breakpoint in app_error_fault_handler and read the id, pc and info values when it hits.

Please note that if the SoftDevice is enabled you will most likely get an assert when you resume running after a pause. For instance, if resuming after having stopped on a breakpoint. The reason for this is the SoftDevice will not be able to meet timing requirements and therefore the internal timing checks will fail, giving an assert within the SoftDevice.

Regards,
Terje