nRF52832 softdevice (with Zephyr)

I'm using version 2.0.2 of NCS

I have code working with nRF52840 in Zephyr

I need to move that code to nRF52832 (also in Zephyr)

My application is failing to start BLE advertising (when using the '832;  works fine with the '840).

I know when working outside the Zephyr environment, I need to change the softdevice from S140 to S132 when changing from the '840 to '832.

I assume that any changes necessary to change chips when in the Zephyr environment are handled via the .dts file (where the '832 is specified) and the build system.

When I attempt to start advertising with the '832, I get a warning:

<wrn> bt_hci_core: opcode 0x2036 status 0x11

and a returned error number of -5.    I believe this is EIO, but unsure what is causing this. (Again, this works with '840)

Here is a screen capture that shows the appropriate portion of the .dts, the call to bt_le_adv_start() and the log window

Looking through the zephyr.map file, I see indications that the soft device S140 is present.    Shouldn't this be the S132?

Parents
  • Hi,

    I am assuming that you are using custom boards for both nRF52832 and nRF52840 based solution you are working on.

    Looking through the zephyr.map file, I see indications that the soft device S140 is present.    Shouldn't this be the S132?

    There should be no references of S140 or S132 in Zephyr and NCS environment, if there are then it is a documentational bug. S140 and S132 are Softdevices names only for nRF5SDK. Those names should not be relevant in Nordic Connect SDK.

    It is also difficult to aid you with the error you are getting without knowing what changes you made to the build environment when moving from nRF52840 chip to .

    What changes exactly did you make when you were porting your project from 840 to 832?

  • Basically, I just changed the .dts to reflect the '832 instead of the '840 and removed a couple of peripherals that won't be used in the '832 board (and aren't available in the '832).   Also had to reduce the allocation for the stacks of a couple of threads due to the smaller SRAM size of the '832.     

    The references to S140 were in the zephyr.map file.   I've been told that these are remnants of the "generic" soft device created for Zephyr that borrowed heavily from S140...

    Not sure why BLE advertising is failing (or what the bt_hci_core warning message is telling me).   What does the bt_hci_core opcode and status indicate?    The return value (-5) indicates EIO...   I'm not sure what this means in this context.    

    Thanks...

  • This should have been straightforward process using Visual Studio code. Please make sure that you use VSC so that you can use this webinar to know what the changes you need to do. The error you are getting could also be if there are any stack corruption or something else.

    The error code looks very similar matching the use case mentioned here. Not sure if this is relevant in the version you are using. They seems to have a patch given in that thread, can you please give it a try?

    cvinayak commented on Mar 15, 2021
    @ppluta
    
    ‘’’
    git fetch [email protected]:cvinayak/zephyr.git github_ext_adv_stop_fix && git cherry-pick FETCH_HEAD
    ‘’’

Reply
  • This should have been straightforward process using Visual Studio code. Please make sure that you use VSC so that you can use this webinar to know what the changes you need to do. The error you are getting could also be if there are any stack corruption or something else.

    The error code looks very similar matching the use case mentioned here. Not sure if this is relevant in the version you are using. They seems to have a patch given in that thread, can you please give it a try?

    cvinayak commented on Mar 15, 2021
    @ppluta
    
    ‘’’
    git fetch [email protected]:cvinayak/zephyr.git github_ext_adv_stop_fix && git cherry-pick FETCH_HEAD
    ‘’’

Children
  • I looked at Case #32866 earlier and saw that the changes had been committed over a year ago.   So shouldn't they be in the latest build already?

    I believe I found the issue.   The device software sets up CODED_PHY advertising.    I believe the '832 doesn't support that.    So I suspect that the error message might have indicated that.    Is there a "secret decoder ring" that defines the status 0x11 being shown in the warning for opcode 0x2036?

    I changed the code to use "normal" advertising and the code works now.

    Thanks...

Related