esp-wifi icon indicating copy to clipboard operation
esp-wifi copied to clipboard

Interesting behavior on ESP32

Open bjoernQ opened this issue 3 years ago • 3 comments

I observed some interesting behavior on ESP32

The ble_esp32 example works fine for me until I comment out this line in the toy-ble-stack: https://github.com/bjoernQ/ble-hci/blob/9c52ccf018756d90df9b90363e04e651589d74de/src/attribute_server.rs#L193

If that log statement is removed / commented-out the ble stack doesn't see the configured services or at least it doesn't find any matching one

I tried to look into that but it still puzzles me

Update: Even a nop there makes things work

bjoernQ avatar May 23 '22 08:05 bjoernQ

Update: It doesn't happen in development mode and also doesn't happen with an opt-level <= 1 (also not with "s" or "z")

bjoernQ avatar May 24 '22 11:05 bjoernQ

Not sure if this is still an issue for you, but to me it sounds like this could be a timing thing.

having info! there causes several bytes to be written to the uart peripheral in a blocking manner. at 115200 baud a string consisting of 12 chars would take ~1ms. If you consider the string "Check service" plus additional characters added such as log level, timestamp, tag, etc. you could easily see a 3ms delay there.

Changing the optimization level could have effects on execution timing and ordering as well.

What happens if you manually insert a delay there?

Mind you, a delay may not be the ideal fix for this, but it would provide a clue as to what may be happening.

Edit: I read your original post more carefully and if adding a single nop there has such a dramatic effect I'm not sure this experiment is even worth it. To me it sounds like a potential optimization problem?

mertzt89 avatar Sep 01 '22 01:09 mertzt89

Hello and thanks for thinking about this odd issue!

My guess currently is also a mis-optimization / mis-compilation unfortunately. I tried to reproduce this in a much smaller example without success so far since tracking down what happens at assembly level in such a big code base is really hard.

bjoernQ avatar Sep 05 '22 07:09 bjoernQ

A lot changed in-between so the original issue isn't reproducible but also the Xtensa toolchain got much, much better. Closing this for now - will create a new issue if anything like that comes up again

bjoernQ avatar Dec 14 '22 14:12 bjoernQ