Something is broken in Puck.js SPI in new Espruino versions

@Gordon any hint how to fix this?

I think the issue is as @fanoush says. Frustrating as I'd come across this years ago and just assumed that at some point they would have added the workaround to the SDK itself :(

Annoyingly it always worked fine for me because I sent more than one byte at a time for my tests.

I'll look into adding a workaround for this.

Ok, just fixed. If you pull the latest from http://www.espruino.com/binaries/travis/master it should be sorted!

Just tested

• MDBT42Q with WIZ850io - works

• Pixl with ethernet shield W5100 - spi communication works, dhcp fails - have to check

It doesn't matter much for 1 byte transfers but in theory the test could be if (count==1 && rx) because it is rx dma what triggers the bug, sending one byte without receiving anything (i.e RXD.MAXCNT==0) works fine. not sure what is actually faster or make more sense - using dma for sending just 1 byte or disabling it, sending and enabling back.

it is rx dma what triggers the bug

Thanks - actually that goes a long way towards explaining how this slipped through!

Now I've made the change that disables DMA for one byte (I don't know why Nordic's solution was that nasty hack with PPI) I was wondering about using it for 2 bytes too. In terms of performance it seems it's probably better not to use DMA in those cases.

I don't know why Nordic's solution was that nasty hack with PPI

I think they wanted to avoid reconfiguring SPI interface from the new EasyDMA SPIM to the older SPI one (as it is actually somehow different HW block inside). That saves them to touch/reset lot of registers including speed, mode, interrupt flags etc. Maybe for some engineer it was not nasty but neat and clever trick to use PPI so it could stay working in DMA mode. But still your fix may be actually more practical.