• State Verified Answer
  • Locked Locked
  • Replies 1 reply
  • Subscribers 69 subscribers
  • Views 590 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 288897
Options
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

DRGN-10613: Please provide explanation for: A memory access fault NRF_FAULT_ID_APP_MEMACC can occur

Marius Heil

Hello,

while migrating our FruityMesh framework to SDK17 I went through all SDK and SoftDevice release notes and migration documents and saw the following:

A memory access fault (NRF_FAULT_ID_APP_MEMACC) can occur in sd_nvic_critical_region_exit() if a high priority SoftDevice interrupt occurs during a critical section, for example
due to radio traffic (DRGN-10613). This issue was present also in previous releases. It can be fixed by editing __NRF_NVIC_SD_IRQS_1 in nrf_nvic.h so that it becomes:
#define __NRF_NVIC_SD_IRQS_1 ((uint32_t)(1U << (MWU_IRQn - 32)))

Now, to me this sounds like it would basically affect almost every application on an nRF52 chipset. As this seems to have been present in mostly every SoftDevice release, I am now asking myself how often this could have happened in real-world scenarios?

As you also provide a workaround, I am wondering why the nrf_nvic.h was not provided with the fix already implemented? Does it have any major drawbacks?

Also, I am wondering why this question has not been asked before Thinking

Thank you,

Marius

  • +1

    Hello,

    What the workaround does is that it will not mask the MWU handler in critical sections, so that it can run be run at the correct time. As I see it, there are no drawbacks to this. 

    I agree that it is a bit strange that noone has asked before. I have not seen the question on DevZone earlier. I guess most people are not reading the release notes. At least not until they discover any strange behavior. 

    Why nrf_nvic.h is not updated is a good question. I guess there must have been some internal communication trouble here. I see that it is mentioned at least in SDK16.0.0's softdevices. It should be said that the last SDK releases was mainly adding support for new devices and critical bug fixes, but that is not an excuse not to include this simple bug fix. 

    I guess the issue is not very prominent, because it rarely triggers. It requires things to happen in a specific order, and at the exact "correct" time in order to trigger. My guess is that one customer found the bug, and it was reported back to us and confirmed. 

    I don't see any reason not to include the fix, although chances are that you would probably never see the issue in actual use. 

    Best regards,

    Edvin

Related
Terms of service