Hi Dialog
Hi Dialog
I have a Da1458c acts as Central device use DSPS Master Project and DA14583 acts as slave(6) uses DSPS Slave Project.
My use case is Central will connect to one slave, receive data and once data received, disconnect from slave(app_easy_gap_disconnet(con_id) called from user_sps_client_data_rx_ind_handler() function) then in user_on_disconnection() i have added user_scan_start() so new slaves started scanned and connected (at a time master connects to only one slave) In slave side once slave disconnected from master, slave will enterds into exetended sleep mode.
i have run the master code without connecting to any slaves... i found no issues..
我已经把所有6 t奴隶到1分钟的睡眠ime, my problem is after some time like 12- 18 hrs of execution master gets hanged...i debugged the code, code stops at wrap_platform_reset()...
in master side i have disabled both extended and deep sleep ... because of this heap configuration will be less.. will it affect ???
what else could be the issue ??
Thank you ..
Hi prasanth,
If the device is operating and after 12-18 hours the device hits the platform reset that means that there is a memory leak in the code, a memory allocation that happens most probably in every connection or transaction and its never freed, so eventually you run out of memory and the wrap_platform_reset() occurs. By increasing the heap it wont be that much of a help since even if you do increase it, it will eventually run out as well in a longer period.
Thanks MT_dialog
Hi Dialog
Thank you for your reply..
The memory allocated will be automatically freed by the kernel, after the pointer has been sent to ke_msg_send(). If the message is not sent, it must be freed explicitly with ke_msg_free().
In DSPS master code only once ke_msg_free() was used ... how can i use this to solve my issue ??
In master code in user_sps_host.c => user_on_connection => user_gattc_exc_mtu_cmd() after this code got stopped...
How can i solve this wrap_platform_reset() issue ??
Thank you...
Hi prasanth,
As mentioned, in your application there should be somekind of memory leakage pilling up after each connection i suppose (when the wrap_platform_reset() occurs make sure that the error code is RESET_MEM_ALLOC_FAIL), you will have to debug this in order to find it, there is no generic method that would allow you to find it. Check if there are any messages that you have send during the customization that you ve done (since this doesn't occur in the original central) and make sure that you are consuming the messages that you get when the message is handled or if you are allocating data they should be freed.
Thanks MT_dialog
Hi Dialog
i have tested by debugging error code was RESET_MEM_ALLOC_FAIL , after commenting all Arch_printf() memory issue disn't happened.
still disconnection issue is there,
My use case is Central will connect to one slave, receive data and once data received, disconnect from slave(app_easy_gap_disconnet(con_id) called from user_sps_client_data_rx_ind_handler() function) , after this slave will disconnect and go to sleep
/*******************************Slave code ************************************/
void user_on_disconnect( struct gapc_disconnect_ind const *param )
{
//default_app_on_disconnect(param);
arch_printf("Device disconnected\r\n");
//if(Console_print) {
// /****************************UART PRINT FUCNTION***************************************/
// uart_init(UART_BAUDRATE_115K2,3);
// uart_flow_off();
// uint8_t something2[] = {"user_disconnected\n"} ;
// uart_write((uint8_t *)something2,sizeof(something2),NULL);
// uart_finish_transfers();
// /***************************************************************************************/
//}
app_easy_gap_advertise_stop();
arch_ble_ext_wakeup_on();
wrbl_env2.sensor_read_time_1 = app_easy_timer( 6000, wake_up_sm ); // 1000 -> 10s
}
/**********************************************************************************************************/
/*********************Master Side*****************************************************************************/
if slave discoonected then in master side gapc_disconnect_ind_handler()-> app_on_doiconnection -> user_on_disconnection() will get called ...
but in a long run user_on_disconnection() is not getting called..what could be the issue ???Please help
Thank you Dialog
Hi prasanth,
I will stick to the point that when commenting out the arch_printf() the memory allocation issue doesn't happen, when printing too much data using the arch_printf() utility you actually allocate data and when having the chance the device will print. If you invoke the arch_printf() too often then you allocate too much memory and if the device doesn't reach the printing point the memory allocation will fail. But as far as i can understand even if you dont see this happen the device still disconnects, but i am not able to understand what exactly is that you are trying to describe, so can you please clarify ?
Thanks MT_dialog
Hi Dialog
Thank you for your reply..
Master is sending disconnection request to Slave , once slave disconnected indication will be send to master and master will receive disconnection indication and call user_on_disconnect()....
Master <--- <------------------------------------> disconnection_req ----------------------------------> Slave
-> disconnected , stops advertising -> enters into sleep
Master <-- <------------------------------------- disconnectc indication -------------------------> send disconnect indication to master
Master <-- Disconnect ind received -----------<-------------
Master <---
some times master is not receiving the indication, so user_on_disconnection() not gets called,(but i can see slave disconnected and enter into sleep ),, after some delay (6 - 7 min)user_on_disconnection() gets called , then runs normally till the time user_on_disconnect gets called user_on_system_powered() is keep on running
In user_on_disconnection() i am starting user_scan_start(), if this is not called master won't be scanning for new devices....
Thank you
Hi prasanth,
So to get a more clear pitcure, on the problematic case the user_on_disconnect gets called on the master side (you get the disconnection indication) but not as soon as the slave sends the disconnection request, is that right ? If that is the case then most probably the link is lost for some reason before the disconnection is issued by the slave, and the link is terminated from the superision timeout and not because of the disconnection command send by the slave, because of that the master "thinks" that the link is still valid. Check at the disconnection callback on the master's side when the issue occurs and check what is the reason that stack returns when that happens.
Thanks MT_dialog