Update examples with new `RadioCoprocessor`

[David-OConnor]

This commit includes breaking changes to the RadioCoprocessor struct. How do you modify the examples to use the second buffer (producer and consumer instead of buf, and altered trait requirements?

[eupn]

Hi @David-OConnor, thank you for reaching out! I'll fix the examples when I have time. For now, you can take a look at https://github.com/Tiwalun/stm32wb55-homekit/blob/471b0d72ad724995f9bb3f7d9580001da2a69e0a/stm32wb55-homekit/src/ble.rs#L26

[David-OConnor]

Thank you - that's perfect

[David-OConnor]

Do you know what could cause the Edystone example to hang at block!(rc.read()), ie where to start troubleshooting?

[eupn]

@David-OConnor,

I think it's good to first verify that coprocessor firmware (BLE stack) is there and works properly. Can you compile and flash an eddystone example from ST and check whether it works? If it won't work, I suggest repeating BLE stack flashing procedure.

If the ST's code works, then this crate's code may hang if it did not received an expected response to the command. This could be caused by unsolicited events from the BLE stack that have to be processed first before receiving an actual command response. I have this worked around by putting all unsolicited events into a small queue first: here.

It may be also interesting to you to check my work with Embassy to enable async BLE support here, but it's outdated quite a bit from the upstream.

[David-OConnor]

Thank you - that's a great idea! Do you use the Cube programmer to do that? I think I need to try the full Edystone example as you said, and also make sure I'm flashing the right firmware to CPU2. Thank you.

[eupn]

@David-OConnor, yes, I remember using cubeprogrammer for that. You can check here for the most recent instructions (in Release Notes web page) as well as BLE stack binaries. I'm using the "full" stack version.

[David-OConnor]

Thanks! You were right - I didn't have a BLE stack installed. Using those Release Notes steps and CubeProgrammer, I updated the FUS and installed the BLE firmware. Got the beacon to transmit successfully to my phone using the ST Nucleo55 BLE Beacon example, flashed from Cube IDE. (I'm on a Discovery board, but it still worked). So, I think CPU2 firmware is now good.

The Rust example is still hanging at the rc.read() step. How could I modify this code (Eddystone example, modified to use global mutexes instead of RTIC), to use the queue?

let evt = {
    if rc.process_events() {
        Some(block!(rc.read()))
    } else {
        None
    }
};

[eupn]

@David-OConnor ok, now let's check what linker file you're using. In order to communicate with C2 we need a special shared section of SRAM to be set up. It's called TL MBOX. If you're using your own HAL, you may have missed these sections defined in this linker file. This sections should be defined. You can just copy & paste these sections into your HAL's linker file. Don't forget to adapt your current linker file with defining a shared SRAM section.

[David-OConnor]

Can I use your memory.x section verbatim for a xG variant? (This is the MMG module, although it works with the Nucleo ST Package evidently). It's what I've been using. I'm on 2 variants to experiment with: One is your HAL and lib directly, with changes only to de-RTIC. The other is with my HAL, with your code modded in. They are both hanging on the same step.

[karlp]

@David-OConnor Did you get these examples sorted out? I've got the https://github.com/Tiwalun/stm32wb55-homekit/ demo running on my board, but having quite a bit of trouble back porting it to these examples. I'm not sure how far I want to push it if it's still hanging on something unresolved?

[David-OConnor]

No. Switched to nRF. :(