Interesting behavior on ESP32
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
Update: It doesn't happen in development mode and also doesn't happen with an opt-level <= 1 (also not with "s" or "z")
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?
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.
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