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

[espruino-discuss]

Posted at 2020-05-18 by SergeP

Hi!
After long time I've started to update my greenhouse controller. It is based on Puck.js, whick is glued in center of the box.
First of all I upgraded Puck.js firmware from v1.92 to have working BLE characteristics (there were bugs with BLE at the old version). After the upgrade I've found that my greenhouse is dry, because TLE94112 is not response.
I made a few tests and discovered that maximal SPI speed to have it responsible is now 740000 baud (and 750000 is already too much) while at v1.92 it works at 1000000 baud and more. So, I think, something is wrong in SPI in new versions. Or, may be, somethink was wrong in old one. In any case, compatibility is broken.
I will change my soft, of course. But be aware because it may be invisible evil bug in the code ;)

[gfwilliams]

Posted at 2020-05-19 by @gfwilliams

Thanks for letting me know - do you think you could post up the code that has the issue? I think 2v05 added SPI using DMA, which would mean that while the bitrate was the same the SPI data probably got pushed out faster (without gaps). I guess it's possible that caused some problems.

[espruino-discuss]

Posted at 2020-05-19 by SergeP

Thank you. I flashed v2.05.27 so my experiments were with the version, and I had 1.v92 before. code is just a modified TLE94112 example code:

SPI1.setup({sck:D28, miso:D30, mosi:D31, baud:integer=1000000, mode:integer=1, order:'lsb' });
var TLE = require("TLE94112").connect(SPI1, D27, D29);
TLE.enable();
TLE.logCtrlReg();
TLE.logSysDiag();
TLE.setDirection(1,1);
TLE.logCtrlReg();
TLE.logSysDiag();
TLE.disable();

[espruino-discuss]

Posted at 2020-05-19 by SergeP

Update: it does not work even at lower speed. I have not recognized still why. Some TLE registers may be written and some may be read but not full control sequence.

[espruino-discuss]

Posted at 2020-05-19 by SergeP

I'll try to go to v2.04

[gfwilliams]

Posted at 2020-05-19 by @gfwilliams

Could you try replacing:

SPI1.setup({sck:D28, miso:D30, mosi:D31, baud:integer=1000000, mode:integer=1, order:'lsb' });

with:

SPI1.setup({sck:D28, miso:D30, mosi:D31, baud:1000000, mode:1, order:'lsb' });

Not sure if that'll help but it wasn't really proper JS before. I'll update the example on the Espruino site.

You could also try using software SPI:

var spi = new SPI();
spi.setup({sck:D28, miso:D30, mosi:D31, baud:1000000, mode:1, order:'lsb' });
var TLE = require("TLE94112").connect(spi, D27, D29);

I'm not 100% sure if Espruino on nRF52 ever supported lsb byte ordering on hardware?

[espruino-discuss]

Posted at 2020-05-19 by SergeP

I'm sure it worked at v1.92 more then 3 years 24h without any breaks. Great stability of your Espruino system!

[espruino-discuss]

Posted at 2020-05-19 by SergeP

It looks like working on 2.04. At least, I see correct voltage transitions on pins.

[espruino-discuss]

Posted at 2020-05-19 by SergeP

Greenhouse control works at v2.04!
By the way, OneWire ds18b20 works fine at 2.04 and breaks time-to-time (about one time of 20) at 2.05.27, too.

[gfwilliams]

Posted at 2020-05-20 by @gfwilliams

Thanks for checking this - and glad you got it working! So you checked the pins? Do you see anything happening at all on 2v05, or is it sending data but not the right data?

OneWire

As far as I know nothing has changed on OneWire - however because the Bluetooth stack jumps in and does some work in the background, ongoing Bluetooth connections can cause it to be unreliable - that might be what you're hitting here.

I doubt anything if different between versions but if you're connected (especially if you sent something to it in the last 2 minutes so it's still in the 'high speed' Bluetooth connection mode) then you will probably see some unreliability.

[espruino-discuss]

Posted at 2020-05-22 by @MaBecker

Used code, stuck in loop with pluged in ethrnet cabel, same module works with PICO

// MDBT42Q
SPI1.setup({ mosi: D22, miso: D20, sck: D19 });
eth = require("WIZnet").connect(SPI1, D18);

---

Attachments:

• Bildschirmfoto 2020-05-21 um 09.23.44.jpg
  
• Bildschirmfoto 2020-05-21 um 07.00.55.jpg

[gfwilliams]

Posted at 2020-05-22 by @gfwilliams

Do you see anything on the capture? It looks for me like everything is working ok? Is the waveform different to what happens on the Pico?

I guess you could try specifying a lower bitrate as @sergep had tried?

Maybe SPI send is working ok but receive isn't? But I'm pretty sure that's tested.

All I can think is maybe now DMA is used from transfers the CS line isn't being asserted properly?

[espruino-discuss]

Posted at 2020-05-22 by @MaBecker

Is the waveform different to what happens on the Pico?

Pico does not have that The initial (idel) state ....

I will solder devices to a perforated board with female pin header and try again.

[espruino-discuss]

Posted at 2020-05-22 by SergeP

By the way, usual issue with DMA-controlled serial communications is that CS line is goes back to inactive state too early, when last byte is sent to DMA subsystem or to shift register, not waiting for it is fully goes out of system. I have seen that even in some hardware USARTs.

[espruino-discuss]

Posted at 2020-05-24 by @MaBecker

Ok, back with a soldered setup, see attached picture.

Pico can handle WIZ550io and WIZ850io without issues over SPI2

// sck is 165KHz
SPI2.setup({ mosi: B15, miso: B14 , sck: B13});

MDBT42Q communication over SPI1.

// sck is 125KHz
SPI1.setup({mosi: D22, miso: D20, sck: D19});
eth = require("WIZnet").connect(SPI1, D18);

// and now it's stuck in the PHY link loop

-> jswrap_wiznet_connect
PHY link status check loop...

Any hints?

---

Attachments:

• IMG_0244.jpg

[espruino-discuss]

Posted at 2020-05-24 by @MaBecker

PICO first 25 decoded SPI traffic

 Decoded Protocol Result
MOSI: 0x00;  MISO: 0x80
MOSI: 0x90;  MISO: 0x40
MOSI: 0x00;  MISO: 0xC0
MOSI: 0xFF;  MISO: 0x00
MOSI: 0xFF;  MISO: 0x00
MOSI: 0xFF;  MISO: 0x00
MOSI: 0xFF;  MISO: 0x00
MOSI: 0xFF;  MISO: 0x00
MOSI: 0xFF;  MISO: 0x00
MOSI: 0x00;  MISO: 0x80
MOSI: 0x80;  MISO: 0x40
MOSI: 0x00;  MISO: 0xC0
MOSI: 0xFF;  MISO: 0x00
MOSI: 0xFF;  MISO: 0x00
MOSI: 0xFF;  MISO: 0x00
MOSI: 0xFF;  MISO: 0x00
MOSI: 0x00;  MISO: 0x80
MOSI: 0xA0;  MISO: 0x40
MOSI: 0x00;  MISO: 0xC0
MOSI: 0xFF;  MISO: 0x00
MOSI: 0xFF;  MISO: 0x00
MOSI: 0xFF;  MISO: 0x00
MOSI: 0xFF;  MISO: 0x00
MOSI: 0x00;  MISO: 0x80
MOSI: 0xF0;  MISO: 0x40

MDBT42Q first 25 decoded SPI traffic

 Decoded Protocol Result
MOSI: 0x00;  MISO: 0x80
MOSI: 0x01;  MISO: 0x40         extra byte 
MOSI: 0x90;  MISO: 0xC0
MOSI: 0x00;  MISO: 0x00
MOSI: 0x01;  MISO: 0x80         extra byte     
MOSI: 0xFF;  MISO: 0x40
MOSI: 0xFF;  MISO: 0xC0
MOSI: 0xFF;  MISO: 0x00
MOSI: 0xFF;  MISO: 0x00
MOSI: 0xFF;  MISO: 0x00
MOSI: 0xFF;  MISO: 0x00
MOSI: 0xFF;  MISO: 0x80
MOSI: 0xFF;  MISO: 0x40
The initial (idle) state of the CLK line does not match the settings.
MOSI: 0x00;  MISO: 0x80
MOSI: 0x01;  MISO: 0x40         extra byte 
MOSI: 0xA0;  MISO: 0xC0
MOSI: 0x00;  MISO: 0x00
MOSI: 0x01;  MISO: 0x80         extra byte 
MOSI: 0xFF;  MISO: 0x40
MOSI: 0xFF;  MISO: 0xC0
MOSI: 0xFF;  MISO: 0x00
MOSI: 0xFF;  MISO: 0x00
MOSI: 0xFF;  MISO: 0x00
The initial (idle) state of the CLK line does not match the settings.
MOSI: 0x00;  MISO: 0x80
MOSI: 0x01;  MISO: 0x40         extra byte 

[espruino-discuss]

Posted at 2020-05-25 by @fanoush

not sure if it is related or there already is fix in espruino code for this issue but there is known bug when sending and receiving one byte over nrf52 spi with DMA, see https://devzone.nordicsemi.com/f/nordic-q-a/16401/sending-single-bytes-over-hw-spi-0xff-appended-every-other-time with link to workaround zip with source or see directly https://infocenter.nordicsemi.com/topic/errata_nRF52832_Rev2/ERR/nRF52832/Rev2/latest/anomaly_832_58.html?cp=4_2_1_0_1_8 for issue described

[espruino-discuss]

Posted at 2020-05-25 by @MaBecker

Wow - thanks for posting!

[espruino-discuss]

Posted at 2020-05-25 by @fanoush

would that explain the issue you see or it is something else? happens only if you are both reading and writing exactly one byte over spi with dma, looks like tx cannot stop after first byte properly if it is waiting for receiving byte. if you don't read and just write one byte it works ok.

[espruino-discuss]

Posted at 2020-05-25 by @MaBecker

Recording MOSI from a MDBT42Q: analog and digital show the same.

---

Attachments:

• Bildschirmfoto 2020-05-25 um 22.23.01.jpg

[espruino-discuss]

Posted at 2020-05-25 by SergeP

@MaBecker, could you add clk and, may be, cs? it is too hard to read SPI data without clk.

[espruino-discuss]

Posted at 2020-05-25 by @MaBecker

// MDBT42Q
SPI1.send([0xf0,0xf0],D18);

---

Attachments:

• Bildschirmfoto 2020-05-25 um 22.49.06.jpg

[espruino-discuss]

Posted at 2020-05-25 by @MaBecker

And this is what we get when using a PICO

SPI2.send([0xf0,0xf0],B10);

---

Attachments:

• Bildschirmfoto 2020-05-25 um 23.05.46.jpg

[espruino-discuss]

Posted at 2020-05-25 by @allObjects

DMA-controlled serial communications is that CS line is goes back to inactive state too early

as in post #14 by @sergep is not necessarily a surprise to me... switching from code controlled / bit-banged-like IO to DMA controlled IO, means that any dependent follow-up line behavior has to be handled with callbacks / interrupts. When Espruino firmware does handle this correctly, there may be an issue when done in the application, as I've done in the past...

Setting the CS line before an unknown sequence of IO calls without passing the ns (NegativeSelect / CS) pin argument except for the last one should always work, since I expect the Espruino firmware takes correct care for he CS line.

[espruino-discuss]

Posted at 2020-05-26 by @MaBecker

@gfwilliams any hint how to fix this?

[gfwilliams]

Posted at 2020-05-26 by @gfwilliams

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.

[gfwilliams]

Posted at 2020-05-26 by @gfwilliams

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

[espruino-discuss]

Posted at 2020-05-26 by @MaBecker

Just tested

• MDBT42Q with WIZ850io - works

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

[espruino-discuss]

Posted at 2020-05-26 by @fanoush

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.

[gfwilliams]

Posted at 2020-05-27 by @gfwilliams

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.

[espruino-discuss]

Posted at 2020-05-27 by @fanoush

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.