Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRFX v2.0.0 NRFX_SWI_USED -> NRFX_EGUS_USED?

Hello, and thank you for making the nRFX components open-source on GitHub!

Now I realize that it's only been up for a day :smile: but most of the changes are reasonably self-explanitory.

The only thing I am asking for confirmation on is the dropping of the SWI driver and it's replacement with the EGU driver.

Is it correct to suppose that NRFX_SWI_USED has been effectively "renamed" to NRFX_EGUS_USED (with value 0x3C for SoftDevices 7.0.1)?

For NRFX_PPI_CHANNELS_USED, NRFX_PPI_GROUPS_USED, and NRFX_TIMERS_USED I can look at the "SoftDevice Specification" and rationalize those values with the ones found in "nrf_sd_def.h".

But the derivation (and correct value) of NRFX_EGUS_USED escapes me.

Thank you!
-Andrew.

Parents
  • Hi,

    Is it correct to suppose that NRFX_SWI_USED has been effectively "renamed" to NRFX_EGUS_USED (with value 0x3C for SoftDevices 7.0.1)?

     Yes. The EGU "uses" the software interrupts, and the EGU and SWI Peripheral shares the same Base Address, so they cannot be used independently at the same time. Take a look at the memory map at this link.

    Looking at the SDS, chapter "Application signals – software interrupts", see this link, the SoftDevices uses SWI/EGU 2,4 and 5. The application could use SWI/EGU 0,1(if SD is not configured to use Radio Notification) and 3. So the correct value for SD_SWI_USED would be 0x34(0b110100). The value 0x3C is wrong, and is from SoftDevice v.3 and earlier, when also SWI/EGU 3 was reserved by the SoftDevice.

  • Okay - that's the same conclusion that I came to!

    Incidentally, the 0x3C value is from the nrf_sd_def.h file in the most recent nRF5_SDK_16.0.0_98a08e2 SDK with SoftDevices 7.0.1 - so that should probably be fixed... :smile:

    Thank you!

Reply Children
Related