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

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 ;)

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.

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();

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.

I'll try to go to v2.04

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?

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

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

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.

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.

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);

2 Attachments

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?

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.

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.

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?

1 Attachment

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 

Usually I debug SPI using oscilloscope. Unfortunately now I have not one at home, and can not use one at work becouse of COVID-19.
By the way, OneWire looks to be not so stable at 2.04 as at 1.92. It returns zero or undefined time to time.

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

Wow - thanks for posting!

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.

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

1 Attachment

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

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

1 Attachment

And this is what we get when using a PICO

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

1 Attachment

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.