firmware debugging procedure

[gusido]

Hi,

First, thanks for an awesome project!

Second - is there any way to debug the firmware? trace? printf? anything alone these lines to help figure out what's going on on the device in real time?

The only reference I could find of "debug" is in the readme concerning debugging baud rate, but i have not idea what to make of it.

Thanks!

[shymega]

There's not, really. @Ralim reverse engineered the buds for flashing, but I think debugging is a long way off. The typical way you'd do it is via UART, which only works whilst the buds are in the case.

However, it could be worth exposing a BLE service - once licensing is done, and CMake is merged, plus refactoring - to print log messages. We'd need to abstract a logger over that.

[Ralim]

Hello 👋🏼

So the buds spew debugging info out the uart all the time. However if you connect them to the charger they go into sleep mode.
So what I do is put a small piece of tape over the 5V pogo pin so they dont see the charger, then I can use the charger as a uart connection to debug output.

This way printf can be used in debugging.

There is no out-of-box debug at the moment.

When I'm adjusting audio related stuff, i put one in and then have the other on the uart to get logs (since they stay sync'ed)

[shymega]

The problem is, that we don't want to assume it's ttyACM* on every system. Some systems, like macOS, use different devnodes. I would rather avoid setting it as a default (a la #99) and instead rely on bestool when I finish refactoring.

Thank you for the PR, though. But I think I'd rather just add a change for the baud rate, and leave it at that...

[nicka101]

You already assume that its ttyACM in a bunch of places and ttyUSB in others, surely its beneficial to have a functional script for the majority of environments (#99 should work anywhere with a linux kernel above 2.5, though not sure about Mac or other BSD derivatives), rather than a non-functional script until an indeterminate future point when bestool is refactored to provide the same?

By all means change it to improve Mac/BSD compatibility, but it seems strange to keep the script present and also broken, and potentially puts off new contributors

[shymega]

I suppose we could merge it. I'm just erring on the side of caution. I'm also keeping in mind the rewrite, which will handle these things.

[nicka101]

Fair enough, do whatever you think is best. I'm just not sure that there's any real downside to (at least mostly) fixing the script now, even if it is going to be replaced with something better/more reliable later

[shymega]

It looks like @Ralim has merged it. I'm mostly cautious with merges, and this is one of my weaknesses. Thank you for taking the initiative to make a PR though - action is by doing. Very much appreciated. And now your work is in the repo!