• State Not Answered
  • Replies 7 replies
  • Subscribers 62 subscribers
  • Views 3141 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 126567
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

  • 0

    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.

  • 0 in reply to 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.

  • 0 in reply to endnode

    I have actually considered using the NVRAM bits as well, we already use one for entering DFU mode and yes I would have to either reduce the complexity / entropy of the settings or store them in flash.

    I do however get the feeling that I should be quite close to having the restrictions lifted on the radio.

  • 0 in reply to endnode

    Calling softdevice_handler_sd_disable from an app time seems to trigger a reboot

  • 0 in reply to endnode

    I believe this function just disables the event handler not SD itself. I was trying to get some example from latest SDK and the only thing I see is ble_stack_stop function in examples\multiprotocol\ble_app_gzll\ble_app_gzll_hr.c. However you have still two more options: look on other Q&S on this forum regarding SD disabling (by quick search it looks there are dozens or rather hundreds of those, just to filter the relevant pieces and finding some recent one which refers to some recent API) or wait if Nordic support team will come and answer this ticket;)

Related