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

[Dan Halbert]

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.

[Dan Halbert]

Hi, thanks for the reply. I'm not sure what you changed in the linked post. Are you saying that the separate RAM block idea implemented by t_prachar is still an issue when using the SD, or are you just confirming that NRFX_SPIM3_NRF52840_ANOMALY_198_WORKAROUND_ENABLED doesn't work with the SD?

The timeslot idea is interesting. We do service other interrupts during a long SPIM3 EasyDMA transaction, and they might read or write the RAM block that also contains the SPIM3 buffer. So I think we will need to use the "separate RAM block" idea described in the errata and dedicate a small RAM block to the SPIM3 buffer, to avoid any chance of transmitting corrupt data. We are writing lots of data to a connected display via SPIM3.

My idea in opening this case was just to get it better documented, because we spent a while scratching our heads about the error before stumbling on the SDK release notes. I appreciate the other suggestions; they should be helpful to others in certain situations.

[AndreasF]

Hi again.

Dan Halbert said:

Hi, thanks for the reply. I'm not sure what you changed in the linked post. Are you saying that the separate RAM block idea implemented by t_prachar is still an issue when using the SD, or are you just confirming that NRFX_SPIM3_NRF52840_ANOMALY_198_WORKAROUND_ENABLED doesn't work with the SD?

 Sorry. I made a mistake by saying this.

I had the wrong DevZone case open, the case I said I had edited the post on was this case: https://devzone.nordicsemi.com/support-private/support/221610#permalink=429201

I did not have a look at your link.

Dan Halbert said:

The timeslot idea is interesting. We do service other interrupts during a long SPIM3 EasyDMA transaction, and they might read or write the RAM block that also contains the SPIM3 buffer. So I think we will need to use the "separate RAM block" idea described in the errata and dedicate a small RAM block to the SPIM3 buffer, to avoid any chance of transmitting corrupt data. We are writing lots of data to a connected display via SPIM3.

My idea in opening this case was just to get it better documented, because we spent a while scratching our heads about the error before stumbling on the SDK release notes. I appreciate the other suggestions; they should be helpful to others in certain situations.

The safest and best choice as I see it would be to go with the timeslot API and only use SPIM3 when you're in a timeslot.

Best regards,

Andreas