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

document in nrfx itself that NRFX_SPIM3_NRF52840_ANOMALY_198_WORKAROUND_ENABLED does not work with SD (and probably in other cases)

nrfx provides NRFX_SPIM3_NRF52840_ANOMALY_198_WORKAROUND_ENABLED, but this workaround does not work with the SD, and probably in other cases as well.

We use nrfx only, not the whole SDK, and only found out about the SD restriction by reading the SDK release notes. See devzone.nordicsemi.com/.../216252. It would be good if templates/nrRF52840/nrfx_config.h included an explicit warning that the workaround may not work in many cases, such as the SD.  Thanks.

If the workaround is going to be fixed to work with the SD, that would be great, but I'm not sure that's possible in simple code, since it requires allocating the buffer in specific RAM blocks.

Parents
  • Hi.

    I've edited that post, you're correct and this was found out later that the workaround in the post you've linked does not work with the SoftDevice.

    I've got two workarounds you can try, one is bulletproof, the other workaround may have issues.

    1) Use the timeslot API (bulletproof)

    Simply use the timeslot API to make sure that the radio is not transmitting when you are using SPIM3

    Read more here, and here.

    2) More workarounds added to your code:

    Unknown said:

    The following workaround describes the usage of SPIM3 with anomaly 198 for the following SoftDevices:
    s140: v6.0.0, v6.1.0, v6.1.1 and v7.0.1

    Please note that access to the base address 0x40000000 is restricted as described by the SoftDevice Specification.
    The following workaround should be applied when the application needs to use SPIM3 + anomaly 198 together with the SoftDevice.

    static void m_mwu_unprotect_0x40000000(void)
    {
      uint32_t mwu_pregion_subs = NRF_MWU->PREGION[0].SUBS;
      mwu_pregion_subs = mwu_pregion_subs & ~MWU_PREGION_SUBS_SR0_Msk;
      NRF_MWU->PREGION[0].SUBS = mwu_pregion_subs;
    }

    void main(void)
    {
      sd_softdevice_enable(...)
      if(planning_to_use_SPIM3)
      {
        m_mwu_unprotect_0x40000000();
      }
    }

    Hope this helps you.

    Best regards,

    Andreas

Reply
  • Hi.

    I've edited that post, you're correct and this was found out later that the workaround in the post you've linked does not work with the SoftDevice.

    I've got two workarounds you can try, one is bulletproof, the other workaround may have issues.

    1) Use the timeslot API (bulletproof)

    Simply use the timeslot API to make sure that the radio is not transmitting when you are using SPIM3

    Read more here, and here.

    2) More workarounds added to your code:

    Unknown said:

    The following workaround describes the usage of SPIM3 with anomaly 198 for the following SoftDevices:
    s140: v6.0.0, v6.1.0, v6.1.1 and v7.0.1

    Please note that access to the base address 0x40000000 is restricted as described by the SoftDevice Specification.
    The following workaround should be applied when the application needs to use SPIM3 + anomaly 198 together with the SoftDevice.

    static void m_mwu_unprotect_0x40000000(void)
    {
      uint32_t mwu_pregion_subs = NRF_MWU->PREGION[0].SUBS;
      mwu_pregion_subs = mwu_pregion_subs & ~MWU_PREGION_SUBS_SR0_Msk;
      NRF_MWU->PREGION[0].SUBS = mwu_pregion_subs;
    }

    void main(void)
    {
      sd_softdevice_enable(...)
      if(planning_to_use_SPIM3)
      {
        m_mwu_unprotect_0x40000000();
      }
    }

    Hope this helps you.

    Best regards,

    Andreas

Children
No Data
Related