You are viewing a plain text version of this content. The canonical link for it is here.

Posted to commits@nuttx.apache.org by GitBox <gi...@apache.org> on 2020/10/27 14:45:51 UTC

[GitHub] [incubator-nuttx] v01d opened a new pull request #2140: nRF52 BLE link-layer

v01d opened a new pull request #2140:
URL: https://github.com/apache/incubator-nuttx/pull/2140

## Summary

This PR implements a mostly complete BLE link-layer for the nRF52 SoC family. This quite an involved PR and could probably split but I wanted to leave that for the end since there's a risk in breaking things.

Changes included in the PR:
- upper-half BLE link-layer interface (bt_ll.h/.c): registers itself as a BLE HCI driver, invokes operations on the arch-dependant lower-half of the link-layer, and implements arch-independent functionality of the BLE LL.
- nRF52 lower-half link-layer (tested on nRF52832):
- supports SLAVE role only (MASTER involves handling multiple connections and scheduling radio time for each)
- implements almost everything of the BLE LL spec (MD or "more data" bit is not handled, though), including LL encryption/authentication (part of the pairing process)
- supports (passive) scanning and advertising

The implementation makes heavy use of PPI when possible, to minimize software handling of events and due to some peculiarities of how the RADIO is designed. This includes some complex setup to ensure proper T_ifs (inter frame separation) of 150uS between last received and sent message is enforced (the RADIO peripheral supposedly has a "shortcut" to support this, but it is quite limited and problematic to use). This was handled with PPI such that a packet will be sent exactly (using a TIMER) 150uS after received packet, if the ISR handling received packet arms this trigger in time.
RTC peripheral was used as much as possible (instead of TIMER) as it uses less power and works during WFI (WFI is left disabled for these tests since I think it should be inhibited once TIMER is being used).

This also includes previously discussed rework on RADIO interface which was too high-level. I would really like to simplify it further since it is implemented as it would eventually be a RADIO1, which does not make sense and overcomplicates its use. I resorted to directly access RADIO registers from here in various cases due to this.

I've also added some real-time debugging facilities using PPI: various RADIO events trigger pin changes, which allow you to use a logic analyzer and verify timings without any software involvement.

There are lots of improvements to be done yet:
- submit the independent parts in separate PRs (I will do this first)
- fix styling
- expose configs to Kconfig
- simplify RADIO further
- improve interaction with RNG: right now I'm accessing registers directly which would interfere with the RNG driver if enabled
- use zero-latency / high priority interrupts for critical ISRs

The last point is the tricky one: I found that sometimes other ISRs delay execution of RX ISR (the most critical one, since it prepares the reponse and must do so before 150uS) and this can lead to a communication break eventually. I worked hard to deal with this and still get a robust connection (BLE allows for six packets lost before dropping connection so there's some leeway), but as other peripherals issue more ISRs this will eventually become unreliable.
This could be improved in a second step since it would involve a lot of complex testing.

## Impact

Adds a new subsystem (BLE link layer) and implementation, should not break anything.

## Testing

Tested extensively using nimBLE stack. I closely inspected RADIO timings, performed very low level RADIO debugging with BLE sniffer and packet decryptor (for paired connections). I've dealt with lot of subtle issues and I think it became very robust in the process. The most notable problem I think would be that of ISR timings.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [incubator-nuttx] v01d closed pull request #2140: nRF52 BLE link-layer

Posted by GitBox <gi...@apache.org>.

v01d closed pull request #2140:
URL: https://github.com/apache/incubator-nuttx/pull/2140


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [incubator-nuttx] v01d commented on pull request #2140: nRF52 BLE link-layer

Posted by GitBox <gi...@apache.org>.

v01d commented on pull request #2140:
URL: https://github.com/apache/incubator-nuttx/pull/2140#issuecomment-805335817


   I'm closing this since I will not be pursuing this anymore now that BLE is supported in nRF52 via SoftDevice. This PR includes a few things that could be merged separately but they are not critical.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [incubator-nuttx] v01d commented on pull request #2140: nRF52 BLE link-layer

Posted by GitBox <gi...@apache.org>.

v01d commented on pull request #2140:
URL: https://github.com/apache/incubator-nuttx/pull/2140#issuecomment-718327415


   I've fixed all style issues and opened various PRs with changes which were contained in this PR. Once those are merged I'll rebase and it should be mostly ready for review (taking into account all above described considerations).


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [incubator-nuttx] v01d commented on pull request #2140: nRF52 BLE link-layer

Posted by GitBox <gi...@apache.org>.

v01d commented on pull request #2140:
URL: https://github.com/apache/incubator-nuttx/pull/2140#issuecomment-761891370

I'm working again on nordic chips and I would eventually like to use BLE. I keep coming back to all this work I've done, and while it was fairly functional and most likley needs some robustness improvements, debugging this was really painful (since it is at the limit of what you can introspect with a logic analyzer and a packet sniffer, and placing a breakpoint on time-critical code breaks everything).

But overall, I don't like the idea that only me knows this code well enough to find any issues. Ideally, someone else would be willing to take over what I've done, test it and help maintain it. But I think it is just too much of a task.

So, I'm currently considering going the softdevice route. To me at least it makes sense since I can assume the controller code is well tested and up-to-date with recent standards. Also, I feel it may not be that hard to make it work (at least not that hard as it is to debug RADIO code). @acassis I remember you mentioned the zGlue project (and I think there was even someone from that project that you mentioned could offer help). It would be cool to know at least about the general strategy they followed, since I see the softdevice uses an SVCall interface and it would probably require some careful consideration to tie it into NuttX.

Anyway, just wanted to let you know about my current thoughts. I realize it is quite a lot of work that may end up nowhere but I'd rather continue putting effort in something that I can trust and works well.

cc: @btashton (since I think you have experience with BLE stuff you may have an opinion about it)

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [incubator-nuttx] v01d edited a comment on pull request #2140: nRF52 BLE link-layer

Posted by GitBox <gi...@apache.org>.

v01d edited a comment on pull request #2140:
URL: https://github.com/apache/incubator-nuttx/pull/2140#issuecomment-718327415


   I've fixed all style issues and opened various PRs with changes which were contained in this PR. Once those are merged I'll rebase and it should be mostly ready for review (taking into account all above described considerations), since I'd like for input on some parts of the code.


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org