#BLE central debugging

1 messages · Page 1 of 1 (latest)

pine arch
#

@hallow rivet

#

are you getting the error at all anymore?

hallow rivet
#

No, I’ve only stumbled upon another weird behavior trying to run the rest of my "diagnostics" code.

#

I now can’t connect as a peripheral (The next test I was doing after central).

pine arch
#

ok. you are the second person I've seen with that error and an erase of the bonding info worked for them too

#

what device is your central?

hallow rivet
#

I was doing both in the same piece of code.

pine arch
#

(I'm back from lunch.)

hallow rivet
#

First as central and then as peripheral

#

I mean from the nRF52840 Express board point of view

#

Reading the BLE workflow commit, I thought it might be linked to the bonding I had with my mobile phone when running the second piece of code where I made the board advertise as a peripheral.

pine arch
#

ok, so your phone is the central that is connecting to you when you advertise

hallow rivet
#

I was just using it to get a hang of what was possible with the hardware I had and dive more into CircuitPython.

pine arch
#

what error are you getting when advertising?

hallow rivet
#

I don’t get any error on the board side of thing but my phone won’t pair anymore

#

where it used to work properly in CircuitPython 6

pine arch
#

what kind of phone is it and what does it do?

hallow rivet
#

It’s a generic android phone and I just paired it

#

I didn’t explore receiving and emitting BLE MIDI from it yet

pine arch
#

so it does work?

hallow rivet
#

It used to work with v6 but won’t connect with v7 wheras the board exits the while condition at line 521 and prints the next debug messages.

#

In the meantime, the phone stays in a connecting state and eventually times out

#

where it used to retain the connection (bond?) in it’s known peripherals list

pine arch
#

it'll remember it only after a successful pairing

#

maybe the disconnect isn't working and you are still connected to the midi plug

hallow rivet
#

checking now

#

The connection seems to be correctly dropped

#

I’m checking if I can still use the central_midi_service after disconnecting

#

Yep, the central_midi_service is still usable after disconnecting

pine arch
#

that is weird

hallow rivet
#

Didn’t expect that

pine arch
#

wellllll I think packet buffer will now reconnect

#

which is underneath midi iirc

hallow rivet
#

I still need to read a bit more BLE specs to understand the lingo. It’s the first time I’m playing with it

pine arch
#

packet buffer is a circuitpython thing

#

it does buffering in and out on a characteristic

#

and preserves packet boundaries

hallow rivet
#

oh, ok then. I’m trying to grasp what’s involved 😉

pine arch
#

it's used by the file transfer service too so it got some tweaks in 7

#

yup, midi uses packetbuffer

hallow rivet
#

Hum. This is way over my head for now but I’m eager to learn!

pine arch
#

learning is fun

#

the next thing to check would be what you are connected to after the loop completes

#

since it isn't your phone apparently

hallow rivet
#

Having a look

#

How can I know what the connection refers to? The repr dosn’t help there.

pine arch
#

I think you can peek into the ._bleio_connection and read the mac address

#

hrm, maybe not

#

you could list all services on the other device

#

using discover_remote_services()

hallow rivet
#

Trying to get to grips with these objects using the REPL before 😉

#

Think I’m getting there.

#

Shoot 3204 again

#

Playing with advertising from the REPL seems to have triggered it again

pine arch
#

ooooh, I just got 3204 too

hallow rivet
#

\o/ At least it’s reproducible

#

Now for the debugging fun

pine arch
#

🙂

hallow rivet
#

Do you have any way to trace what triggers it ?

pine arch
#

there are a couple options

#

one is turning on verbose ble debugging in the build

#

which will print more info

#

the other is just adding prints to the build

hallow rivet
#

I was hoping for something more advanced (a debugger maybe) but this works

pine arch
#

you can connect a debugger to it but ble is timing sensitive

hallow rivet
#

Of course

pine arch
#

and debugger halts and the nordic soft device will get unhappy

hallow rivet
#

It’s just me thinking about my Segger mini order not arriving…

#

I can’t wait to play with it!

pine arch
#

🙂

hallow rivet
#

It’s been tens of years since I’ve done hardware debugging and the landscape has changed quite a bit

#

Need to relearn a thing or two

#

Thanks for the great resource!

pine arch
#

np

#

it's my job 🙂

hallow rivet
#

and it’s a nice one 😄

#

So, what does it takes to build CircuitPython? I’ve not ventured there yet.

pine arch
hallow rivet
#

Let’s have a go. I have a feeling I will regret trying the WSL way and not wiping out my Linux Thinkpad but that’s how I learn!

pine arch
#

🙂

#

I'm debugging it now too

hallow rivet
#

Well, I’m not there yet. I’m preparing my circuitpython build environment 🙂

pine arch
#

good to have a build environment setup anyway 🙂

hallow rivet
#

absolutely!

#

It was on my list for a bit later though 😉

pine arch
#

😄

#

ah, 3204 is identities in use

#

(not duplicates)

hallow rivet
#

nevermind, I’m getting sleepy it’s not the same error number. doh

pine arch
#

it is the same one

#

and I think it is the same issue

#

the CP core will advertise automatically once paired

#

and start_scan should stop it

hallow rivet
#

That’s the new BLE workflow feature for v7, right?

pine arch
#

yup

hallow rivet
#

So, without looking at the code, the missing part is stopping the advertisement if the user wants to take the reigns so to speak

pine arch
#

right, because scanning and advertising share an identity list

hallow rivet
#

I’m now starting to get it. It reinforces the need to read the Bluetooth spec tomorrow to get a better understanding of the architecture.

pine arch
#

I think the identity thing is a nordic restriction

hallow rivet
#

Yeah, the shared identities list is an implementation detail that resurfaces here

#

(Trying to build my first CircuitPython)

#

(And failing miserably! Yes, another opportunity to learn)

#

Pull Request incoming!

#

Next error, I was missing the proper libc

#

Now building my first build \o/

#

(In slow motion since I forgot to add the -j flag)

pine arch
#

thanks!

hallow rivet
#

Thank you for the great resources!

#

Ok. Time to test a bleeding edge version of CircuitPython. Here goes nothin’

pine arch
#

it's pretty close to rc.1. it shouldn't be too bad

hallow rivet
#

Well, seems I’ve lost USB connectivity. Bootloader is fine so no worries.

pine arch
#

what version of gcc are you using?

hallow rivet
#

arm-none-eabi-gcc 11.2.0

#

I grabbed the first one in Arch packages

#

Had to try it before bothering with a manual install 😉

pine arch
#

haha, I'm on arch

#

I just made a pr to fix it

hallow rivet
#

lol

#

what a coincidence!

pine arch
#

10.3 is used in the CI

hallow rivet
#

GitHub needs a button to grab patches from PR for quick hacky tests

#

Using your patch I recovered USB! Thanks 😄

#

I don’t have any juice left today. I’ll try and get back to it tomorrow.

#

Thanks for the ride!

pine arch