Mechanism to block DA14580 to receive GATT read/write response from a controller

⚠️
Hi there.. thanks for coming to the forums. Exciting news! we’re now in the process of moving to our new forum platform that will offer better functionality and is contained within the main Dialog website. All posts and accounts have been migrated. We’re now accepting traffic on the new forum only - please POST any new threads at//www.xmece.com/support. We’ll be fixing bugs / optimising the searching and tagging over the coming days.
6 posts / 0 new
Last post
dhrishi
Offline
Last seen:3 years 3 months ago
Joined:2017-02-10 09:56
Mechanism to block DA14580 to receive GATT read/write response from a controller

Hi,

We have a peripheral solution in which DA14580 is connected over UART to our microcontroller. DA14580 queries the controller for the values of characteristics for GATT read/write requests from the central.
We catch the read (ATTS_READ_REQ_IND) and write (GATTC_WRITE_CMD_IND) events in user_catch_rest_hndl()
Is there a mechanism using which we can block till we get the response from the controller over UART for the read or write request and then send the response from user_catch_rest_hndl()

In short, we need to send a read/write request from user_catch_rest_hndl() and wait till the response is received (UART interrupt) and then send the response data from the user_catch_rest_hndl(). Could you please let us know how can this be done. Any pointers, examples would be helpful.

Thanks,
Hrishikesh

Device:
MT_dialog
Offline
Last seen:2 months 3 weeks ago
Staff
Joined:2015-06-08 11:34
Hi dhrishi,

Hi dhrishi,

I dont quite understand the use case, you mention that the 580 is attached to the external MCU (i suppose this is what you mean when you say controller) and the controller provides the values for the characteristics.

  • As a first example to understand what exactly you are saying, lets take for example the ATTS_READ_REQ_IND this will occur as soon as a central will read a characteristic of the 580, so you will get that message and you would like to block sending the confirmation to the central until you read the value from the external processor ? Is that what you are saying.
  • Regarding the GATTC_WRITE_CMD_IND, this will be triggered when a central writes to the specified characteristic, so you would like to block before sending a confirmation (if a confirmation is required by a peripheral, since there are writes that do not require a response) ?

So, do the above scenarios descibe what you would like to do ?

Thanks MT_dialog

dhrishi
Offline
Last seen:3 years 3 months ago
Joined:2017-02-10 09:56
Yes. Exactly. That is right.

Yes. Exactly. That is right.
How do we do that

MT_dialog
Offline
Last seen:2 months 3 weeks ago
Staff
Joined:2015-06-08 11:34
Hi dhrishi,

Hi dhrishi,

没有例子你想做什么since the databases values are kept in the internal database of the 580, also i am not quite sure about the block that you mentioned, since as soon as you get the indication (that a central has read or written a characteristic) the SDK will just report that to the application and its up to you what you are going to do. As far as i can tell, regarding what you woulid like to do, most of the commands used in the BLE spec are sequential, that means that most of the commands (including the Read Request and the Write Request) when issued by the central they should be confirmed by the peripheral which means that the central cannnot send an additional request if it doens't get a response from the previous command (this request/response scheme is like a flow control that the BLE protocol implements). So you can get the indication from the read or the write request, catch them in the catch_rest function and start your UART transaction, the central wont issue any additional request until you send a confirmation message, so as soon as your UART transaction is complete you can send the confirm on the other side of the link. Also be aware that not all commands follow the request/response scheme, for example a write command (write with no response) will trigger your indication but the central wont wait for a response and it can still issue an additional command while processing the previous one and that requires an additional flow control scheme.

因此,基于上面你可以写通过UARTwhen a write indication occurs and read from UART when a read indication comes from the central. Regarding sending the value that you ve read from UART, as i ve mentioned in a different post you can't just send the value that you have obtained through UART directly but you have to set the value in the internal database as soon as you have the read indication and then send the confirmation for the read. So upon read reception trigger the UART transaction invoke the attmdb_att_set_value() in order to set the value in the database and then dg_atts_read_cfm() to send the value.

Also, be aware that while you are reading from UART, you will have to be awake, so no sleep in order to have the XTAL16.

Thanks MT_dialog

dhrishi
Offline
Last seen:3 years 3 months ago
Joined:2017-02-10 09:56
I already have attmdb_att

I already have attmdb_att_set_value() and dg_atts_read_cfm() in my implementation.My concern is that, when ATTS_READ_REQ_IND would be received in user_catch_rest_hndl(), I will have to first send request to the external MCU over UART to get the value of that characteristic and on reception of data, call the above two functions. Right?

Now, the UART response from the external MCU will be from the interrupt context. So, how can I make the current executing thread in user_catch_rest_hndl() to wait until an appropriate response is received from the external MCU. Else it will return by calling calling above two functions with garbage/incorrect values and the read response to the central would be incorrect.

In short, we should wait till the response from UART (from interrupt context) is received and same is saved in the GATT database and then the read confirmation is sent out.

MT_dialog
Offline
Last seen:2 months 3 weeks ago
Staff
Joined:2015-06-08 11:34
Hi dhrishi,

Hi dhrishi,

Yes, this what i am thinking, get the indication, start the UART transaction, get the data, and send the confirmation with the value obtained by the UART.

The 580 its not a thread based system, it just has a scheduler that schedules messages and executing the corresponding callbacks evertime the rwip_schedule() function runs from the main loop. So what you can try is, as soon as you get the reading indication, start the UART transaction or set up the UART for receiving data from the external MCU (that depends on your implementation and how the interaction will be) and either leave the catch_rest handler (by setting up an read interrupt) or stay there (executing the UART transastion, in that case you can't stay as long as you want executing UART transaction since you will start missing BLE event and eventually you will get disconnected since you wont be executing the scheduling function since you wont go through the main loop) as soon as the interaction gets completed. When the UART interrupt hits or the transaction has finished then just send the confirmation message to the client.

Thanks MT_dialog