-
Notifications
You must be signed in to change notification settings - Fork 0
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.
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
Fault when building with mbed-os master #1
Comments
Indeed, it is quite nice to have the traces!
Seems suspicious. have you tried to change the
Is probably unrelated. |
Yes, I have tried to change that setting. It doesn't really help. I've set it to 40, and up to 64. Even if the service is added successfully, the application always crashes when a connection is made. I'm not sure how adding a single service with 5 characteristics could exceed the default maximum of 20 characteristics with authorization. None of the FOTA characteristics have authorization specified by default. You would know better than me, but my guess is maybe the CCCD for notifiable characteristics might have authorization by default? I'm not sure why this happens for the FOTA Service on master and not the LinkLoss or CurrentTime services, the only difference I see is that the FOTA service uses long-format UUIDs. Are long-format UUIDs tested in the automated BLE integration tests? |
@pan- I have a working example and update python script. You can flash I have a few ideas for how we can streamline the build/update process. I will write these up before my vacation begins tomorrow. |
Awesome, what was the Mbed issue ? |
The solution was to build with mbed-os-6.9.0, master is still broken 😅 |
Also, those binaries are for the nRF52840_DK target. EDIT: @pan- You might be able to recreate the issue here with a simpler example (that doesn't require all the signing and bootloader complexity) by simply building the FOTA service integration test with mbed-os master. |
@pan-
I'm not sure what's going on here, this repo works when I build it with the mbed-os-6.9.0 tag. But when I build it with the current master (84e5f1e03eed2227d91937c38ab862297ee9c2d6) it results in the following trace output:
I've tried to reproduce the issue using the
BLE_GattServer_Experimental
example inmbed-os-example-ble
by building it with similar configuration, enablingmbed-trace
, and using the latest mbed-os master branch (commit hash as above). For some reason that example application works whereas this one does not.I'm thinking there may be some issue with the (very nice to have) BLE traces. Perhaps it is related to the fact that this
FOTAService
uses 128-bit UUIDs? I couldn't pinpoint what was going on and it stumped me for several hours....I will write up a guide on how to build, sign, and test this tomorrow. It requires the use of the
mbed-mcuboot-demo
bootloader (see my repositories) and the build steps are similar to what's in that README.I haven't tested anything beyond starting a FOTA session (and the subsequent erasure of the update BD). The
PeriodicBlockDeviceEraser
in this repository breaks up a large erase operation into many small ones so as not to block the BLE process for too long.The text was updated successfully, but these errors were encountered: