-
Notifications
You must be signed in to change notification settings - Fork 7.6k
Writing >20 Bytes to Characteristic causes all registered Write Callbacks to fire #4046
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I found that the same bug was present in the original Esp32 snippets. The following link is the original issue and was fixed and closed |
Yes, I still blow away the BLE files in the v1.0.4 arduino-esp32 board support package release and replace them with what is on master from nkolban/esp32-snippets... I wish this would get fixed in this package so I can stop having to do that. Unfortunate that the vestigial code is more stable than the official code in this regard. I'm sure there's a good reason though. |
The reason is that nobody actually made a PR for this. This is not the "official" code here. It's just a snapshot from the moment that Colban started his new job and @chegewara stopped supporting the lib. PRs are welcome |
I can open a PR, it's just likely to be a pretty size-able change set and I'm not really equipped to evaluate the full scope of that change set for correctness. My fear would be that it would overwrite / revert fixes that might exist in this repo. I'll give it a shot anyway. |
Sorry I deleted the other comment (It was from my job account) Sorry, I'm not the right one to open a PR. Have almost 0 experience with C++, I'm learning in the process! Either way, thanks for the product and the library! |
Where are the BLE files in Kolban's snippets? I only see the BLE Scanner. After checking heap space last night, I realized that the default BLE consumes 120k of heap! |
See my PR... they come from ./cpp_utils |
Thanks. I downloaded the files and replaced the Espressif files. However, am I doing something wrong or does BLE really consume so much space? Free heap before BLE: 147564 |
about 70kB |
Btw - I had a variant of this bug also, so I tried @vicatcu's awesome PR. Alas, I can report a regression compared to the code currently in master: In my app I use light-sleep, and to do so I have to carefully not just turnoff bluetooth, but stop and delete my various services before going to sleep. That still works fine. But when I go to recreate my services after wake, something is spinning somewhere - and that step never completes. I'll debug more - but I thought I should mention it. |
So I merged the pull-request mentioned in espressif#4046, and noticed a regression compared to the code currently in master: In my app I use light-sleep, and to do so I have to carefully not just turnoff bluetooth, but stop and delete my various services before going to sleep. During this process I would call BLEDevice::deinit(false). That still works fine. However, when my app woke from light-sleep and needed to restart bluetooth it was hanging in registerApp: ``` Starting bluetooth [D][BLEDevice.cpp:80] createServer(): >> createServer [D][BLEServer.cpp:291] registerApp(): >> registerApp - 1 [D][FreeRTOS.cpp:164] take(): Semaphore taking: name: RegisterAppEvt (0x3ffdd7b0), owner: <N/A> for registerApp [D][FreeRTOS.cpp:173] take(): Semaphore taken: name: RegisterAppEvt (0x3ffdd7b0), owner: registerApp ``` To I poked around a bit, and it seems that in the PR espressif#4050 branch, there is a change compared to master. A bit of code that used to be #ifdef was changed to be #ifndef. Which has the effect of never setting initialized to false. If initialized is left true, my call to BLEDevice::init() was having no effect. So I've changed this ifdef back to what master had, and now my app works nicely and the corruption I was previously seeing in my BLE structures seems fixed (the original goal of pulling in 4050.
Okay - all happy now and OMG this PR fixes nasty BLE problems I was having. So thank ya'll for your work! |
Informed by the discussion in the bug and the code in 'that other branch' the fix was clear. Just set a flag if we start handling a write, and use that flag to guard the long write complete call.
[STALE_SET] This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions. |
any questions on the associated #4086 PR? I suspect others will want it. |
[STALE_CLR] This issue has been removed from the stale queue. Please ensure activity to keep it openin the future. |
As explained in title: When sending more than 20 bytes to any Characteristic causes all registered Write Callbacks to fire.
Board: ESP32 DevKit v1
Chip: ESP32D0WDQ6 (revision
Features: WiFi, BT, Dual Core, 240MHz
Auto-detected Flash size: 4MB
Core Instalation date: 01/05/2020
IDE: Arduino 1.8.12
Upload Speed: 115200
Computer OS: Windows 10 Pro
Description:
Same as title
Example Sketch
Debug Messages:
The text was updated successfully, but these errors were encountered: