10000 BLE on ESP32 inconsistent init time (sometimes > 10s) · Issue #5489 · micropython/micropython · GitHub
[go: up one dir, main page]
Skip to content

BLE on ESP32 inconsistent init time (sometimes > 10s) #5489

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.

Sign up for GitHub

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

Jump to bottom
Closed
Zukial opened this issue Jan 3, 2020 · 11 comments
Closed

BLE on ESP32 inconsistent init time (sometimes > 10s) #5489

Zukial opened this issue Jan 3, 2020 · 11 comments
Labels
port-esp32

Comments

@Zukial
Copy link
Zukial commented Jan 3, 2020

Initiating and activating bluetooth with

import bluetooth
ble = bluetooth.BLE()
ble.active(True)

normally take around 200ms to execute. But sometimes it takes over 10 seconds.

occurs with esp32-idf4-20191220-v1.12.bin

Further Details at this forum post.
@dpgeorge
Copy link
Member
dpgeorge commented Jan 6, 2020

This is most likely a hardware or IDF issue. Best to wait for a stable IDF version which includes nimble (3.3.1), see #5282

@saramonteiro
Copy link

It is also happening to me using the following version:

esp32-idf4-20200115-v1.12-68-g3032ae115.bin

It also takes a non-deterministic time. By the way, I just realized here at #5524 that BLE is now supported by the IDF v3 firmware, and the IDF stable version is v3, not v4. I am gonna try it and observe if this change solves the problem.

@saramonteiro
Copy link

Used esp32-idf3-20200116-v1.12-68-g3032ae115.bin and the inconsistent init time persists.

@lchzeng
Copy link
lchzeng commented Mar 26, 2020

Used esp32-idf4-20200326-v1.12-307-gad004db66.bin and the inconsistent init time persists.
Code：
start = utime.ticks_ms()
s=self._ble.active(True)
print('delay={:d}ms\r'.format(utime.ticks_diff(utime.ticks_ms(), start)))
Serial-out：
23:27:54:102-< �[0;32mI (3031) phy: phy_version: 4180, cb3948e, Sep 12 2019, 16:39:13, 0, 0�[0m
23:28:04:290-< GAP procedure initiated: stop advertising.
delay=10273ms
23:28:04:322-< GAP procedure initiated: advertise; disc_mode=2
MicroPython v1.12-307-gad004db66 on 2020-03-26; ESP32 module with ESP32
Type "help()" for more information.

@sunbeamer
Copy link

@dpgeorge Any updates on when this issue will be looked at?

Thanks.

@dpgeorge
Copy link
Member

I looked in to this problem. I was able to reproduce the slow start up time with an IDF example (bluetooth/nimble/bleprph) on both v3.3.2 and v4.0, but to get the problem to show needed the nimble task to be pinned to core 1 (which is what MicroPython's config does). The problem does not show up on the very latest IDF version, v4.2-dev-1126-gd85d3d969 (with nimble pinned to core 1).

Pinning nimble to core 0 makes the problem go away in both v3.3.2 and v4.0, as far as my testing showed (on both the IDF example and MicroPython firmware).

Summary: this can probably be fixed by one of the following:

  1. pin everything to core 0 (MicroPython task and nimble task) when BLE is enabled;
  2. update to the latest IDF

Since point (2) is non-trivial, and we don't yet support LAN or PPP for v4.x, I suggest option (1), at least for now.

@tve
Copy link
Contributor
tve commented Apr 22, 2020

Hmmm, doesn't pinning MP to core0 (that's the "PRO" core, right?) effectively makes the second core unused? That's pretty drastic too... At what point is the cure worse than the disease?

@dpgeorge
Copy link
Member

doesn't pinning MP to core0 (that's the "PRO" core, right?) effectively makes the second core unused? That's pretty drastic too...

It was like this for a long time, because dual-core mode was very unreliable in the early days (and still is it seems).

Sometimes the BLE init delay is around 30 seconds which is really unusable. And since it looks fixed in very recent IDF versions putting it all on core 0 is just a workaround for now.

@sunbeamer
Copy link

@dpgeorge Thank you for investigating and offering the workaround of pinning both the Micropython and Nimble task to core 0.

I can confirm this works.

@dpgeorge dpgeorge mentioned this issue Jun 7, 2020
Closed
@jimmo
Copy link
Member
jimmo commented Aug 19, 2020

This issue has been a major frustration while trying to test #6343

I would like to suggest that we go with @dpgeorge's suggestion of pinning both MP and NimBLE to Core 0 until the issue is fixed in the IDF. (I've added a commit to #6343 to do exactly that). This appears to be causing more issues than just slow startup, and generally the reliability has improved since pinning both to core 0.

According to the IDF 4.1-rc1 release notes, this issue might be fixed by "Fixed HCI timeout issues when using multiple cores and sleep is enabled" (I don't really want to go down the rabbit hole of figuring out the implications of "and sleep is enabled").

I agree with @tve that it's unfortunate to put everything on the PRO core, but right now it makes BLE very hard to test and it's not a good experience for users. The other fix (if we don't want to wait for 4.1) would be to make the NimBLE->MP bindings work across cores (this means making the BLE ringbuffer and MP scheduler multi-core safe).

dpgeorge pushed a commit to dpgeorge/micropython that referenced this issue Sep 8, 2020
@jimmo @dpgeorge
esp32: Pin MicroPython and NimBLE tasks to core 0.
115d8bd 
MicroPython and NimBLE must be on the same core, for synchronisation of the
BLE ringbuf and the MicroPython scheduler.  However, in the current IDF
versions (3.3 and 4.0) there are issues (see e.g. micropython#5489) with running
NimBLE on core 1.

This change - pinning both tasks to core 0 - makes it possible to reliably
run the BLE multitests on esp32 boards.
dpgeorge pushed a commit to dpgeorge/micropython that referenced this issue Sep 8, 2020
@jimmo @dpgeorge
esp32: Pin MicroPython and NimBLE tasks to core 0.
0fea509 
MicroPython and NimBLE must be on the same core, for synchronisation of the
BLE ringbuf and the MicroPython scheduler.  However, in the current IDF
versions (3.3 and 4.0) there are issues (see e.g. micropython#5489) with running
NimBLE on core 1.

This change - pinning both tasks to core 0 - makes it possible to reliably
run the BLE multitests on esp32 boards.
dpgeorge pushed a commit to dpgeorge/micropython that referenced this issue Sep 8, 2020
@jimmo @dpgeorge
esp32: Pin MicroPython and NimBLE tasks to core 0.
311b851 
MicroPython and NimBLE must be on the same core, for synchronisation of the
BLE ringbuf and the MicroPython scheduler.  However, in the current IDF
versions (3.3 and 4.0) there are issues (see e.g. micropython#5489) with running
NimBLE on core 1.

This change - pinning both tasks to core 0 - makes it possible to reliably
run the BLE multitests on esp32 boards.
@dpgeorge
Copy link
Member
dpgeorge commented Sep 8, 2020

Fixed in 311b851 by pinning everything to core 0. Can be improved in the future after updating to a newer IDF that fixes the bug.

@dpgeorge dpgeorge closed this as completed Sep 8, 2020
@glenn20 glenn20 mentioned this issue Oct 7, 2020
Merged
@jimmo jimmo mentioned this issue Jan 6, 2021
Merged
@breedx2 breedx2 mentioned this issue May 12, 2021
Closed
breedx2 added a commit to breedx2/micropython that referenced this issue May 13, 2021
@breedx2
esp32: Pin MicroPython to core 1 again.
c20cfb1 
This follows up on micropython#5489, where we changed the esp32 core pinning
to core 0 in order to work around an issue with IDF < 4.2.0.
Now that IDF > 4.2.0 is available, we allow pinning back to core
1, which eliminates some problematic callback latency with
wifi enabled.
dpgeorge pushed a commit that referenced this issue Jan 21, 2022
@breedx2 @dpgeorge
esp32: Pin MicroPython to core 1 again.
3570785 
This follows up on #5489, where we changed the esp32 core pinning to core 0
in order to work around an issue with IDF < 4.2.0.  Now that IDF > 4.2.0 is
available, we allow pinning back to core 1, which eliminates some
problematic callback latency with WiFi enabled.

NimBLE is also pinned to core 1 - the same core as MicroPython - when using
IDF >=4.2.
leifbirger pushed a commit to leifbirger/micropython that referenced this issue Jun 14, 2023
@breedx2 @leifbirger
esp32: Pin MicroPython to core 1 again.
3ab9039 
This follows up on micropython#5489, where we changed the esp32 core pinning to core 0
in order to work around an issue with IDF < 4.2.0.  Now that IDF > 4.2.0 is
available, we allow pinning back to core 1, which eliminates some
problematic callback latency with WiFi enabled.

NimBLE is also pinned to core 1 - the same core as MicroPython - when using
IDF >=4.2.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
port-esp32
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@tve @lchzeng @jimmo @dpgeorge @sunbeamer @saramonteiro @Zukial
0