cpu/cc2538: fix spi_transfer_bytes()

[benpicco]

Contribution description

In the in_buf == NULL case, spi_transfer_bytes() would only write DR for every out byte, but then loop reading DR only while SPI is busy.

This is not correct, we have to read as many data bytes as we write, otherwise data bytes remain in the FiFo and will corrupt subsequent reads.

While at it, I also took the chance to clean up spi_transfer_bytes() by factoring out DR access into a helper function.

Testing procedure

Run @guyyst's tests application from #12128 (comment) on the openmote-b.

Before this patch, the driver would sometimes read both interrupt status registers as 0 (or some other weird value) and in turn not service the interrupt.

With this the test is running smoothly.

Issues/PRs references

The issue was discovered while testing the at86rf215 driver on the openmote-b.

[fjmolinas]

Had to go back though some of my SPI basics, but change makes sense (was confused by the fact that the Rx_FIFO and TX_FiFO need to behave like a shift register for SPI). I'll test ASAP.

[fjmolinas]

I'm trying to replicate the failure using the mentioned example, its been going for 1hour and no failure yet...

[fjmolinas]

I'm trying to replicate the failure using the mentioned example, its been going for 1hour and no failure yet...

Argh, I'm unable to reproduce the issue now... Since the change still makes sense, I'll do a no-regression test.

[fjmolinas]

Argh, I'm unable to reproduce the issue now... Since the change still makes sense, I'll do a no-regression test.

Otherwise maybe @guyyst can verify it fixes the issue for him?

[guyyst]

I'll have access to our OpenMotes towards the end of the week. I'll try out the fix and report back then.

[guyyst]

Weird, I'll have to echo @fjmolinas findings. I tried the example on 2.4-GHz and Sub-GHz with and without this patch and observed the same behaviour. Neither of them stopped receiving even after 5+ minutes.

My only guess is that some other commit to #12128 since the last time I tried this in November already fixed the issue.

[fjmolinas]

I've had a lot of trouble reproducing the issue. I had it come back a couple of time to the disappear. None the less I haven't seen it when this change has been. I'm going to ACK this because:

• The change itself makes sense
• I have tested there is no regression
• I have not seen the bug when this PR was in
• @benpicco provided offline more info on how he found the fix:

I've never seen the issue on the sam0 boards, so I checked what else it might be. And the SPI implementation on cc2538 was broken before (#12336), so I checked if there is something strange still
and yea, reading & writing bytes to and from SPI should always work the same no matter what values the in or out buffers have, so I fixed that
afterwards I would not see the issue again
(I also printed the values I read from the interrupt flags register and they would make no sense, e.g I would get an interrupt and both registers would read 0)