Hello Dialog,
I've recently run into a problem using notifications that I'm hoping you might help with.
一段时间我一直在逃跑g custom application based on the ble_app_peripheral example which records sensor data in an external memory. I implemented a command in an Android app that retrieves the recorded data and stores it in a file on an Android tablet. To do this (based on advice from this forum) I used a 20 byte characteristic with read, write, and notify properties. The procedure is to enable notifications from the Android app, then send a custom command to the DA to begin data transfer. This is simply sends 20 bytes with a notify message and waits until the notify is confirmed via CUSTS1_VAL_NTF_CFM, then sends 20 more bytes with another notify message. Then repeating the process until all the expected data is sent. This works great and I have sent large blocks of data using this technique.
Recently I tried adding notifications to another characteristic for some sensor data to be displayed when it changes. This characteristic already had the notify property defined but I hadn't used it. This also appears to work OK. When notifications are enabled the sensor data changes are sent when they are detected and I can display it on the Android tablet. This happens at a slow rate of once per second. However, in testing I found if I disable the sensor data notifications and then attempt a data transfer as described above, it starts, transfers a few thousand bytes and stops. The DA needs to be reset when this occurs. So far, I've been unable to determine why this is happening. It doesn't make sense to me why enabling/disabling notifications on another characteristic would cause a malfunction on my data transfer characteristic. In my experience with the DA14580 this appears to be similar behavior to messages not being consumed and accumulating until the system fails. I don't know how to verify if that's what is happening or not though ..... or if the problem is something else.
Any ideas what might cause this and/or what I might look at? So far I've carefully looked over the database description in user_custs1_def.c and the handlers in user_custs1_impl.c and haven't seen anything incorrect so far. I had used the ADC example in ble_app_peripheral as a guide as to what was required.
谢谢你,马克斯
Hi Max44,
From the behaviour that you are describing i would assume the same thing, that you are generating messages and not consuming them (apparently the device hits an assertion of not being able to allocate memory), perhaps the connection interval of the current connection isn't frequent enough so that data that you are sending are not actually send but accumulated. I am not sure that i fully understand the testing that you perform. Check the assertion that you get and make sure that you hit the fail to allocate memory assertion and since that you have assured that this is the reason that your device stops responding check if you accidentally somehow generate data without actually sending them.
Thanks MT_dialog
MT,
Sorry. I was trying to be brief and not burden you with too much information. I'll put together a more detailed description of my testing that hopefully will give you a clearer picture what I'm attempting to do and the malfunction I'm getting.
I don't think I'm getting an assert error as you mentioned above, but I'll revisit that. I tried looking at where I stopped in the Keil debugger but it wasn't clear. I do get the data transfer to run without error from a power on state. That is, I read and transfer 17,000 bytes (** see below) from SPI flash to my Android tablet and stored the data in a file on the tablet. Upon examination, the data in the tablet file looks correct. This seems to indicate that the connection interval is adequate, but I left it at the ble_app_peripheral example settings, which I think are 10 min and 20 max. I had thought that the custs1 code would adjust to what the connection interval is as by the following comment from custs1_task.c:
The GATTC_CMP_EVT message that signals the completion of a GATTC_NOTIFY
* operation is sent back as soon as the notification PDU has been sent over
* the air.
So this sends the CUSTS1_VAL_NTF_CFM that I get in user_peripheral.c and I use that to indicate I can send the next notify. Doesn't this imply the BLE packet has been transmitted? And in my case, since I'm sending 20 bytes, it should go out in a single BLE transmission.
What's bothering me is that the data transfer works by itself and can send a large amount of data to the Android tablet. If I go and activate notifications on another characteristic, it causes the data transfer routine to fail. I'm having difficulty figuring out what the interaction is ..... or if I've done something stupid and/or have an error in the code somewhere. So far I haven't found an error in the code, but I'll keep looking.
谢谢你,马克斯
(** 17,000 bytes). 17,000 may seem like a strange number, but I'm really looking for 16,384 bytes. Because of the 20 byte characteristic (which as you know is determined by the BLE data payload), my algorithm for data transfer reads 1000 bytes from flash and pushes it out to the Android tablet with 50 x 20 byte notifications. I decided the easiest thing to do would be to run 17 iterations of this loop and let the tablet or PC data anaysis routine sift through the data and discard the extra. The BLE module and Android tablet are set up for a fixed 17,000 byte transmit and receive loop.
MT,
我终于发现是错误的。原来一个ndroid app was not sending a descriptor to disable notifications even though a button on the GUI was touched to do so. The app I'm using is generated by Bluetooth Developer Studio + Android Studio and behaves similar to Blue Loupe. My sensor data characteristic had GUI buttons for read, write, and enable notifications to interact with the DA14580 custom service I implemented. Touching the enable notifications button sends a descriptor with the enable value and changes the button to disable notifications. The Android app was just re-sending the enable value when you touch the button to disable notifications. Since I was updating sensor data once per second, I was expecting that disabling notifications would switch back to updating the characteristic database for a read. Instead I was continuing to send notifications when they were disabled on the tablet, resulting in an error.
I found that disabling notifications was a problem experienced by other Android developers with Android BLE service and there are some fixes suggested online if anyone else on this forum encounters this.
I made the correction and it looks like I'm receiving the descriptor value to disable notifications on the DA14580 now. And the data transfer now appears to be working after enabling and disabling notifications on my sensor data characteristic.
So we can now close this topic. Thanks for listening!
Regards, Max
Hi Max44,
Thanks for sharing.
Best Regards MT_dialog