long SPI communication unreliable

RE: long SPI communication unreliable

choehyunho — Tue, 26 May 2020 06:55:14 GMT

After I tried to change transfer size, found my mistake eventually.

Because SPI transfer length is limited to uint8_t, every transfers should break into several ones less than 256.

So, the following codes works fine. Thanks, Edvin.

    for (int i = 0; i < len; i += UINT8_MAX) {
        nrf_drv_spi_xfer_desc_t datadesc = NRF_DRV_SPI_XFER_RX(buf + i, len - i > UINT8_MAX ? UINT8_MAX : len - i);
        APP_ERROR_CHECK(nrf_drv_spi_xfer(&spi, &datadesc, 0));
    }
...
    for (int i = 0; i < len; i += UINT8_MAX) {
        nrf_drv_spi_xfer_desc_t datadesc = NRF_DRV_SPI_XFER_TX(buf + i, len - i > UINT8_MAX ? UINT8_MAX : len - i);
        APP_ERROR_CHECK(nrf_drv_spi_xfer(&spi, &datadesc, 0));
    }

RE: long SPI communication unreliable

choehyunho — Thu, 21 May 2020 02:04:27 GMT

With quite a long term testing, my current codes is proven to quite reliable/stable.

Still massive transfer in single shot is not working, and it easily caused ENC28J60 chip to gone, and it makes hard to analyze the problem with logic analyzer.

It seems to be happened whenever I tried to send/receive hundreds of bytes with nrfx_spim_xfer().

Still, I have a interest in this issue, but have another higher priority problems to solve.

I'll test with increasing the single transfer size, after I can make spare time.

RE: long SPI communication unreliable

choehyunho — Wed, 29 Apr 2020 12:37:59 GMT

First, I'll explain the problem situation.

The ENC28J60 is the ethernet controller communicated with SPI, and I made driver for it.

It works fine, but sometimes (very rare, once per a day) the communcation causes problem.

I made a small extra code to compare SPI sent data to re-read data, and it does not match.

That is why I try to make sure the SPI communication is working perfectly.

Second, the actual work function is nrfx_spim_xfer() and NRFX_CHECK(NRFX_SPIM_EXTENED_ENABLED) is false.

Since I am using Mesh SDK, this setting may be default. SDK version is 16.0.0.0 & Mesh SDK is 4.0.0.

I tested with 52833 DK, and now I also have custom board based on it.

Third, currently I am on longivity test with my new custom board.

At first glance, the error rate seems to be greatly reduced, but not sure yet.

Still the single burst transfer is not working, and when I checked with analyzer, I couldn't find difference between the good/bad codes. I'll investigate further later.

RE: long SPI communication unreliable

Edvin — Tue, 28 Apr 2020 09:34:41 GMT

[quote user="choehyunho"]The disabled block fails with various errors. Maybe incorrect data sent/received.[/quote]

Ok. You need to check using a logic analyzer whether the data that is sent is the same that is on the gpios. Perhaps you can give an example of an error. What are you trying to send, and what is being received?

What SDK version do you use? And what modules do you use? What functions are being called inside nrf_drv_spi_xfer()?

nrfx_spim_xfer() or nrfx_spi_xfer()?

What does NRFX_CHECK(NRFX_SPIM_EXTENDED_ENABLED) return?

I would continue to dig into this, but there are quite a few options. Why don't you tell us what the function calls that are being called inside nrf_drv_spi_xfer()? This depends on your sdk_config.h settings.

Is this a large problem? Why not just use the implementation that works?

I don't really have a lot to work with here.

RE: long SPI communication unreliable

choehyunho — Mon, 27 Apr 2020 16:34:37 GMT

It returns NRF_SUCCESS. Otherwise, the code would block because of APP_ERROR_CHECK().

I checked SPI signals at the early stage of development for simple register access and found nothing strange. (My scope is not so fully capable for triggering/capturing this burst read/write, because this transfer will be started after several small register accesses. Anyway, I'll try to check whether some different pattern shows between good/bad cases.)

And nRF52 DK and my custom board shows the same behavior, and changing SPI frequency to lower/lowest also shows no difference.

Again, my functions send/receive hundreds of bytes on SPI line in single transfer.

Isn't it suitable using single nrf_drv_spi_xfer() on this purpose?

I haven't never suffered from this kind of problem in different platform.

RE: long SPI communication unreliable

awneil — Mon, 27 Apr 2020 13:11:47 GMT

[quote userid="88182" url="~/f/nordic-q-a/60677/long-spi-communication-unreliable/246775"]The extra delay with for{} loop may caused difference, but normally it should not[/quote]

Shouldn't it?

If removing the extra delays makes it too fast - that would explain it ...

Again:

[quote userid="6462" url="~/f/nordic-q-a/60677/long-spi-communication-unreliable/246721"]Have you used a scope or analyser to see what's happening on the wire?[/quote]

and

[quote userid="26071" url="~/f/nordic-q-a/60677/long-spi-communication-unreliable/246852"]Have you tried analyzing the SPI wires when using this block? What does it look like compared to the other block[/quote]

we don't have access to your hardware - so only you can do that!

RE: long SPI communication unreliable

Edvin — Mon, 27 Apr 2020 12:59:03 GMT

Hello,

You say that the #if 0 block doesn't work. Does nrf_drv_spi_xfer() return something other than 0 (NRF_SUCCESS) when you use this block? Have you tried analyzing the SPI wires when using this block? What does it look like compared to the other block?

RE: long SPI communication unreliable

choehyunho — Mon, 27 Apr 2020 11:13:27 GMT

First, I admit that I missed one thing to explain.

This SPI connection is made with spi_config.ss_pin = NRF_DRV_SPI_PIN_NOT_USED;.

It is because transmitting single byte command and transmitting multple bytes immediately cannot be expressed with single nrf_drv_spi_xfer() call.

So, I first lower SS pin as GPIO output, and after transfer, up it.

With this condition, the two codes SHOULD BE EXACTLY THE SAME, AFAIK.

The extra delay with for{} loop may caused difference, but normally it should not, if the nrf_drv_spi_xfer() is properly made.

So, does it mean nrf_drv_spi_xfer() for multiple bytes has timing bug?

RE: long SPI communication unreliable

awneil — Mon, 27 Apr 2020 09:01:37 GMT

[quote userid="88182" url="~/f/nordic-q-a/60677/long-spi-communication-unreliable/246702"]The disabled block fails with various errors[/quote]

You need to quantify that!

A key part of debugging is getting a proper handle of what is actually going wrong!

Have you used a scope of analyser to see what's happening on the wire?

[quote userid="88182" url="~/f/nordic-q-a/60677/long-spi-communication-unreliable/246702"]the active block is working fine[/quote]

So why not just do that?

The obvious difference at first sight is that one does it as a single transaction, but the other as individual bytes - so the timing is clearly going to be different. And, perhaps, the use of the Slave Select ... ?

[quote userid="88182" url="~/f/nordic-q-a/60677/long-spi-communication-unreliable/246702"]Which one is sending/receiving (buf + 1) numbers of data[/quote]

That's not what I said.

But I misread the code anyhow: I thought it said '1' - not 'i' - so ignore that comment!

Sorry.

But maybe avoid the use of single-letter variable names.

RE: long SPI communication unreliable

choehyunho — Mon, 27 Apr 2020 08:25:05 GMT

The above codes are extracted from my actual driver code.

The disabled block fails with various errors. Maybe incorrect data sent/received.

In the other hands, the active block is working fine.

This is why I am asking, and why the single bulk transfer is working differently with multiple single transfers.

I cannot understand what you mean. Which one is sending/receiving (buf + 1) numbers of data?

Give your great answer for me.

RE: long SPI communication unreliable

awneil — Sat, 25 Apr 2020 09:55:36 GMT

[quote userid="88182" url="~/f/nordic-q-a/60677/long-spi-communication-unreliable"]some strange behaviour[/quote]

Would you care to be a little less vague?

[quote userid="88182" url="~/f/nordic-q-a/60677/long-spi-communication-unreliable"]it does not work[/quote]

http://www.catb.org/esr/faqs/smart-questions.html#code

What testing / debugging / investigation have you done to find the problem ?

What have you found so far ?

https://www.avrfreaks.net/comment/2418156#comment-2418156

EDIT

[quote userid="88182" url="~/f/nordic-q-a/60677/long-spi-communication-unreliable"]The #if 0 blocks should not be different from active ones[/quote]

Well, one key difference is that one uses 'buf' and the other 'buf+1' ...