nrf52840 errata [198] - data corruption on SPIM3

[Dor Sadeh]

Hi, I'm using the nrf52840 with Zephyr and I indeed encountered data corruption on SPIM3 transmitted data.

How do I implement the proposed workaround?

"Reserve dedicated RAM AHB slave for the SPIM3 transmit buffer, not overlapping with application data used by the CPU."

[Simonr]

Hi 

Most workarounds for anomalies like this in Zephyr/the nRFConnect SDK are set by enabling a config, and the same goes for the erratum 198. In your project's nrfx_config_nrf52840.h file the following define is by default set to 0: NRFX_SPIM3_NRF52840_ANOMALY_198_WORKAROUND_ENABLED. If you set it to 1, this workaround will be implemented from nrfx_spim.c I believe.

Best regards,

Simon

[Dor Sadeh]

I've set in nrfx_config_nrf52840.h:

#define NRFX_SPIM3_NRF52840_ANOMALY_198_WORKAROUND_ENABLED 1

 

And I still get data corruption.

I'm not writing anything to the transmit buffer used by spim3 while transmitting data as suggested in the workaround.

[Simonr]

Can you try debugging by setting a breakpoint at where the workaround is called and implemented (nrfx_spim.c, lines 204 and onwards).

I guess it might also not be related to this erratum. If so I guess we need some more info on what you're doing. Is your project based on any of the sample projects in Zephyr/nRFConnect SDK?

Best regards,

Simon

[Dor Sadeh]

I put a breakpoint to verify that the errata code is executed, and it is.

My app samples sensors and streams the data to flash. The flash used the spim3.

The problem did not occur when I moved one of the sensors to work with spim3, and the flash uses spim2.

Maybe since the sensors sampling uses ppi with short transactions (<10 bytes), and the flash uses long 2KB spi transactions without ppi, the problem does not occur now.