dsps v5.150.2 device disconnects after

8 posts / 0 new
Last post
roinovi
Offline
Last seen: 1 day 17 hours ago
Joined: 2015-11-04 18:11
dsps v5.150.2 device disconnects after

hello
i am using the da14580 to transfer data via uart from my custom board to an app on the phone
in order to test the device i am using the dsps app on an iphone:

custome board (mcu)<=>da14580(device)<=>ble---------ble<=>dsps app running on iphone(host)

when i tried to run the v 3.150.2 on the da14580 device, it works fine-> i saw the data on the application (dsps) running on the iphone
however when i tried to use the v 5.150.2 on the da14580 device, the device disconnects from the app only when the mcu starts sending data via uart
as seen in the pics attached.
if the mcu doesnt send data via uart, the device stays connected to the app(host), only when the data transmission begins, it disconnects after a second
can it be a buffer issue or something like that?

Device: 
SDK: 
MT_dialog
Online
Last seen: 2 min 50 sec ago
Staff
Joined: 2015-06-08 11:34
Hi roinovi,

Hi roinovi,

I haven't encountered such an issue while operating with the DSPS, the fact that when the device starts sending data could be cause by an overflow of a buffer but if you use the flow control feature this should not occur. Check what exactly happens to the 580 when tha MCU starts sending data over the UART and the 580 disconnects, does the device resets ?

Thanks MT_dialog

roinovi
Offline
Last seen: 1 day 17 hours ago
Joined: 2015-11-04 18:11
it was a buffer issue.

it was a buffer issue.
now its working fine except for the advertising stage meaning:
if the external mcusends data during the advertising phase, than the advertising drops after 1 sec.
however if the mcu doesnt send data during this phase(i physically disconnect the pin) then the da14580 is able to connect to the dsps app , and after the pairing i reconnect the tx pin(physically) from my mcu to the da14580 and i see the data on the dsps app.

my question is : i want to set inactive (GPIO_SetInactive(0,7)) the tx pin on the initialization of the device, and after the pairing phase set the pin active (GPIO_SetActive(0,7))

where in the code do i need to insert these 2 commands?

MT_dialog
Online
Last seen: 2 min 50 sec ago
Staff
Joined: 2015-06-08 11:34
Hi roinovi,

Hi roinovi,

I am not sure i understand the question since you have the port/pin 0_7 as a tx pin you wont be able to use it as a gpio set and un-set it with the GPIO_SetActive() command, what you can do is reconfigure the pin as a plain GPIO (PID_GPIO) and set the state of the pin that you would like. Now regarding where you can set the pin, you mention that you would like to do that when the device is initialized, you can place the reconfiguration in the .app_on_init callback and in the end of the pairing phase the .app_on_pairing_succeded is triggered.

Thanks MT_dialog

roinovi
Offline
Last seen: 1 day 17 hours ago
Joined: 2015-11-04 18:11
hello

hello
i have reconfigured the uart rx pin to PID_GPIO and set it to active however i cant see the data flowing through the uart pins (and nothing on the dsps app)

void set_pad_functions(void) // set gpio port function mode
{

/*
* Configure application ports.
i.e.
GPIO_ConfigurePin( GPIO_PORT_0, GPIO_PIN_1, OUTPUT, PID_GPIO, false ); // Set P_01 as Generic purpose Output
*/
GPIO_ConfigurePin( GPIO_UART1_TX_PORT, GPIO_UART1_TX_PIN, OUTPUT, PID_UART1_TX, false );
GPIO_ConfigurePin( GPIO_UART1_RX_PORT, GPIO_UART1_RX_PIN, INPUT_PULLUP, PID_GPIO /*PID_UART1_RX*/, true );

is there another place in the code i need to reconfigure?

in regards to the initial advertising problem when the uart pin is active ( and data is flowing in )
in the debug session i see that the code is stuck on the assert warning in :

static void user_periph_push(uint8_t** wrdata, uint16_t write_amount)
{
bool send_flow_off = false;

//write items to buffer
user_buffer_cfm_write(&periph_to_ble_buffer, write_amount);
if (user_buffer_write_check(&periph_to_ble_buffer, wrdata, RX_CALLBACK_SIZE) != RX_CALLBACK_SIZE)
{
ASSERT_WARNING(0);
}

is there a way (other than to set the uart rx pin inactive) to fix this?

MT_dialog
Online
Last seen: 2 min 50 sec ago
Staff
Joined: 2015-06-08 11:34
Hi roinovi,

Hi roinovi,

The RX functionallity from the pin is detached, you will still see data on the RX line if the external device keeps sending but this doens't mean that they go into the UART line of the 580, the RX line of the 580 is still driven by the Tx of your external MCU, but there will be no UART interrupts of receiving data, so the user_periph_push() should not be invoked in order to cause that error. Despite the reconfiguration of the pin, If you are getting an error at this point then that means that apparently the available space in the ring buffer is not enough, you will have to check why that happens on your setup, since this should not occur in normal operation.

Thanks MT_dialog

roinovi
Offline
Last seen: 1 day 17 hours ago
Joined: 2015-11-04 18:11
just to clarify

just to clarify
the ASSERT_WARNING(0) happens when i configure the PID_UART1_RX (and then the code is stuck on that line)

when i configure PID_GPIO the code does not stuck but i cant see data on the dsps (because as you said no uart interrupt accures)

1) how do i fix the ASSERT_WARNING(0) when i configure PID_UART1_RX?
it happens because the ring buffer is full when the uart data is coming through but not getting out because there is no ble connection yet right?
2) if i configure PID_GPIO, what needs to be done (and where) in order to invoke a uart rx interrupt?

MT_dialog
Online
Last seen: 2 min 50 sec ago
Staff
Joined: 2015-06-08 11:34
Hi roinovi,

Hi roinovi,

The ASSERT_WARNING(0) that you ve mentioned occurs indeed when there is no room available in the periph_to_ble_buffer and in the DSPS project, if properly used, that should not occur. So if you are getting this warning that means that you are not using flow control, since in the DSPS if the buffer reaches the highwatermark level (RX_BUFFER_HWM) it issues a flow off to the external device, so either you dont use flow control or the external MCU continues to send data to the 580 while the flow off is on. So, bottom line you are flooding the buffer with data that exceed the ammount of the buffer and you never free buffer positions. There is no fix in that, you will have to respect the flow control or customize the code depening on your requirements.

Regarding the configuration of the PID_GPIO, the fact that you are changing the functionallity of the pin will not allow you to get interrupts for UART since internally the pin is no longer connected to the UART module of the 580.

Thanks MT_dialog