I have the following code built with Single Connection SDK and another one, with Multi Connection SDK:
I show part of the code below:
In file att.c:
// RxTx Communication
// 001b - 1e
{4,ATT_PERMISSIONS_READ, 2,2,(u8*)(&my_primaryServiceUUID), (u8*)(&my_RxTx_ServiceUUID), 0},
{0,ATT_PERMISSIONS_READ, 2, sizeof(my_RxTxCharVal),(u8*)(&my_characterUUID), (u8*)(my_RxTxCharVal), 0}, //prop
{0,ATT_PERMISSIONS_WRITE, 2,sizeof(my_RxTx_Data),(u8*)(&my_RxTxUUID), (&my_RxTx_Data), &RxTxWrite}, //value
{0,ATT_PERMISSIONS_RDWR,2,sizeof(RxTxValueInCCC),(u8*)(&clientCharacterCfgUUID), (u8*)(RxTxValueInCCC), 0}, //value
In app.c
int RxTxWrite(void * p) {
uint8_t inData[30];
rf_packet_att_data_t *req = (rf_packet_att_data_t*) p;
rf_pkt_test *req1 = (rf_pkt_test*) p;
for(int i=0; i < 20; ++i){
inData[i] = req1->data[i];
}
#if UART_DEBUG
at_print("packet 20 bytes\n";
at_print_hexstr(inData, 20);
at_print("req->dat 4 bytes\n");
inData[0] = req->dat[0];
inData[1] = req->dat[1];
inData[2] = req->dat[2];
inData[3] = req->dat[3];
at_print_hexstr(inData, 4);
at_print("\n");
#endif
ble_sts_t status = blc_gatt_pushHandleValueNotify(slave_connHandle,RxTx_CMD_OUT_DP_H, inData, 4);
return 0;
}
From the phone connected to the device I sent text "test"
log result received:
packet 20 bytes
On the device with firmware built using Multi Connection SDK, the received data is incorrect - A2 11 48 A5
I have noticed that 20 bytes in the received packet is always the same, no matter what data is sent from the phone. So the 20 bytes in the packet don't contain the received data.
No related topics |
SOLVED!
After doing a search for "otaWrite" (as used in the sdk example), I found in ota_server.h the following function declaration:
int otaWrite(u16 connHandle, void * p);
So, changing my function declaration from:
int RxTxWrite(void * p) //as was used in Single Connection SDK
to
int RxTxWrite(u16 connHandle, void * p) //for Multi Connection SDK
fixed the problem.
The data read is correct.
It would be good if it was mentioned in the handbook. It would save me so much time.
Hi Wes,
Noted. Thanks for your suggestion.