What are the requirements for going from an active BLE connection to sending a carrier wave?

[Visti Andresen]

Hi

I have seemingly successfully created a firmware that sends a continuous carrier wave using radio_test.c from nRF5_SDK_12.1.0_0d23e2a/examples/peripheral/radio_test/

And it seems to work great as long as I don't start the BLE stack (the current draw is in the expected rang for the radio running)

As sort for icing on the cake I would however like to enter the radio test mode using a BLE characteristic. Which would also allow the transmit power, frequency and duration of the test to be specified.

When I receive the command to enter test mode I call:

sd_ble_gap_disconnect(service_.conn_handle, BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION) To disconnect the current connection.

I then call sd_ble_gap_adv_stop() To stop the BLE stack from advertising

I even tried to adding some timer based delays, NRF_RADIO->TASKS_DISABLE and calling softdevice_handler_sd_disable()

However the chip reboots whenever I call radio_tx_carrier(power_, 3, frequency_)

As it is possible to coexist with the BLE stack sharing the radio if you time it correctly it should be possible use the radio even after the BLE stack has been activated.

I just seems to be missing some steps in politely asking the BLE stack to deactivate and allow me to enter radio test mode.

Does anyone know what I'm overlooking?

Kind Regards Visti Andresen

[endnode]

As entering radio test will terminate the connection anyway I would simply soft reset the chip and in boot-up procedure read some flag (there are 2 bytes of RAM registers on nRF52 which survive soft reset or alternatively store config in flash) which would say if your should start standard BLE stack and your profile or enter this one-purpose radio test mode. Once you are done with the test sequence according to parameters pushed previously you can again reset your MCU and during boot switch to BLE part.

This looks maybe like a hack on a first sight but I've actually seen this in several production FWs where DTM or radio test were bundled like this to "full" BLE FW functionality and switch was done during boot based on various conditions.

[endnode]

If you decide to continue with your architecture then I believe problem is that you are not disabling the SD properly and so you get hard-fault when touching restricted HW block directly.