• State Not Answered
  • Replies 5 replies
  • Subscribers 25 subscribers
  • Views 317 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 283464
Options
nRF5 SDK is not maintained anymore
More Info: Consider nRF Connect SDK for new designs

nRF52840 NRF_RADIO->SHORTS Register Resetting.

user73768

Hi,

We have to enable the radio shorts in our developing multi link firmware. (We let any node connect to 3 other nodes at the max  ( 1 as a slave and 2 as a master ))

We are using SDK 15 and here is the code portion of write into register.

 NRF_RADIO->SHORTS = (((1 << RADIO_SHORTS_READY_START_Pos) & RADIO_SHORTS_READY_START_Msk)  |   ((1 << RADIO_SHORTS_END_DISABLE_Pos) & RADIO_SHORTS_END_DISABLE_Msk) );
when we read after writing its giving 19 but when we read again after any one device got connected its showing 0.
Why this register is resetting ? 
Parents
  • 0

    Hi

    Are you implementing the entire RF protocol from the ground up, or are you running some other protocol in the background?

    Unless you are disabling the radio from time to time, or there is some other protocol that is also using it, I am not sure why the register would be reset. 

    Best regards
    Torbjørn

  • 0 in reply to user2116

    Thanks for the reply

    We are using the  Fruitymesh Code and top of it our application code. Not implementing the entire protocol from the ground. The fruitymesh code is implemented by using SDK15. 

  • 0 in reply to user73768

    Hi

    You mean you are altering the Fruitymesh implementation directly, or running some other radio protocol on the side?

    It is limited what support we can provide for Fruitymesh applications since this is not a software protocol that we provide, but if you have the source code available have you had a look at the code to see where the SHORTS register is accessed?

    If you are planning to develop multi link firmware is there any reason you couldn't just use a standard SoftDevice itself?
    They typically support up to 20 connections at the same time. 

    Best regards
    Torbjørn

  • 0 in reply to user2116

    Hi

    We can ignore the fruitymesh code now.

    I am using SDK 17 ble_app_blinky_c and ble_app_blinky example code.

    When I write the TIFS time into register (NRF_RADIO->TIFS = 50) its setting correctly but its resetting to default setting after enabled the nrf_sdh_enable_request().

    If I write after enabled the softdevide its giving the softdevice error.

    1. Why it is resetting after enable the softdevice( nrf_sdh_enable_request())?
    2. Is it possible to write after enabled the softdevice? Or we have to set it before the softdevice enabled?
    3. How can I change the TIFS time from 150us to 50us in this example code? Can you provide any example to change the TIFS time?
  • 0 in reply to user73768

    Hi 

    All the radio registers are controlled by the SoftDevice when it is enabled, and you should not try to alter any of these, as it will lead to unpredictable behavior and software crashes.

    If you want to change basic radio parameters you either need to develop your own protocol from scratch, or start out with something like the ESB protocol. 

    Alternatively you could start out with the open source Bluetooth stack in Zephyr and make changes to that, but then you will no longer be Bluetooth compliant, and I am not sure how easy it will be to release a product in this case. 

    Is there any particular reason you need to change the TIFS value in the first place?

    Best regards
    Torbjørn

Reply
  • 0 in reply to user73768

    Hi 

    All the radio registers are controlled by the SoftDevice when it is enabled, and you should not try to alter any of these, as it will lead to unpredictable behavior and software crashes.

    If you want to change basic radio parameters you either need to develop your own protocol from scratch, or start out with something like the ESB protocol. 

    Alternatively you could start out with the open source Bluetooth stack in Zephyr and make changes to that, but then you will no longer be Bluetooth compliant, and I am not sure how easy it will be to release a product in this case. 

    Is there any particular reason you need to change the TIFS value in the first place?

    Best regards
    Torbjørn

Children
No Data
Related
Terms of service