Dear Dialog support,
I have ported the DA14583 IoT SDK to Murata ZY with DA14580.
Mostly I changed GPIO assignments, and so far most things work as expected.
However when connected e.g. with the IoT app, and then forcing the sensor out of range, it becomes unresponsive and a reset/power cycle has to be issued.
In the UART debug interface I can not observe a message following the event, especiallyDBG_MSG("DISCONNECTED\r\n");fromuser_on_disconnectdoes not appear (UART debug does work fine and shows other messages).
I am not aware to have modified any routines that could cause this behavior.
Could you assist me in tracing this issue?
Best regards
Johannes
Device:
Additionall findings:
1. I noticed that
gapc_disconnect_ind_handleris not executed when going out of range (but it is when I manually click "disconnect" in the IoT app).Hi gme_johannes,
Could you please clarify which your issue is since the gapc_disconnect_ind_handler when you manually click "disconnect" from the IoT application? Is this related with the out of range?
Thanks, PM_Dialog
Hi PM_Dialog,
因为我不知道从哪里开始跟踪wn the bug, I have searched the code randomly for function calls related to disconnections, and have put UART debug outputs to see whether they are executed. The
gapc_disconnect_ind_handlerwas the first function I investigated.I compared the situation "regular disconnect" vs. "out of range disconnect".
Please let me know which are the proper functions that I should investigate, to find out where it freezes.
BR Johannes
Hi gme_johannes,
Could you please run the firmware in debug mode, hot attach the debugger and try to find where the code gets stuck?
Thanks, PM_Dialog
Hi PM_Dialog,
unfortunately I never got JTAG/SWD running (see alsohttps://support.dialog-semiconductor.com/comment/20501#comment-20501).
我希望你能向我描述的行为in the SDK following and out-of-range disconnection, such that I have a chance to investigate it only with UART, but without debugger.
Best regards
Johannes
Dear PM_Dialog,
I got debugging with SWD running.
Please see attached screenshot where the code seems to stop.
Is there more information I can provide?
Best regards
Johannes
Hi gme_johannes
The most obvious reason that the wrap_platform_reset() is occurred is due to memory allocation failure, which means that there is a memory leakage in your software, you allocate data somewhere and you never release them (you can verify that in the parameter error of the function, which should be RESET_MEM_ALLOC_FAIL). Selecting the optimal heap for your application, you should experiment with via changing the sizes of the heaps in the da1458x_config_advanced.h file. There is nothing wrong with the memory allocation, but it depends how much memory you are trying to allocate, apparently you are trying to allocate more memory than what is available and you get that assertion. Could you please make sure that the firmware gets stuck into the wrap_platform_reset()?
Thanks, PM_Dialog
Hi PM_Dialog,
indeed the error is RESET_MEM_ALLOC_FAIL.
I have added very little code to the original IoT project, mainly to handle two more LEDs.
I am using EXTENDED SLEEP, such that the heap size should be calculated automatically, correct? So, what can I modify?
When I execute the code and force out of range for BT, the debugger will stop in the wrap_platform_reset(), yes.
BR Johannes
I have modified the heap size in da1458x_scatter_config.h:
and now I do not see the issue anymore.
Nonetheless I would like to know how to determine the appropriate value. How was "1024" chosen?
How can I test that the heap size is enough for my application?
BR Johannes
Hi gme_johannes,
Glad that you figured your issue out. There is not any specific way to determine the appropriate value. The value of the heap size should be decided experimentally.
Thanks, PM_Dialog