Armbian kernel 4.14 rc7 banana pi m2 about nrf24 HOT 26 CLOSED

Hello Sergey,

thanks for the ticket. I did not add any raspberry pi specific code (except of using raspberry pi kernel).

First dev_printk occurrence from nrf24_rx_thread is called in nrf24_read_reg (called via nrf24_is_rx_fifo_empty)

Could you please check if spi pointer is NULL there? If it is not NULL, check what is in spi->dev (as for example the name of device is taken from there).

Thanks,
Marcin

P.S. I am sorry for late answer, but I did not receive any email notification about that.

from nrf24.

Hello Marcin,
thanks for the reply.
I will check what you said and report. It seems like the memory is totally corrupted in those receive/transmit threads. I am just curious why you didn't use UART strategy instead of those 2 threads..

I tried a couple more drivers similar to yours but all was unsuccessful. So I am still interested in making it work.

from nrf24.

So, maybe the problem is in the layer below i.e. spi driver?

What do you mean by "the memory is totally corrupted in those receive/transmit threads" ?

I am sure there is a lot of bugs there, so any hints are welcome!

Marcin

from nrf24.

It may be too... Those sunxi devices are not well supported. "Memory corrupted" meaning that many pointers there are pointing to some strange data. I will give you more info later.
Didn't you think about using UART driver approach? I.e. implement UART driver based on RF stuff.
I tried also this project https://github.com/melomaa/nrf24l01 , it is not working either on my hardware, but at least it is not crashing ...

from nrf24.

Hello Marcin
I have some news here. I found an issue in rx_thread function.

It seems like condition should look like the following:

if (pipe > NRF24_PIPE5) {
...
}

But when I change it the way above then my board will hang at startup.

from nrf24.

Hello

this "pipe" in this context is a value of filed RX_P_NO of STATUS register.

Documentation says:
000-101: Data Pipe Number
110: Not Used
111: RX FIFO Empty

Not sure why you are getting pipe == 6 which is "Not Used". I have not observed such behavior.

This condition:

Your change is correct, but I would write it like following:
if (pipe >= N_NRF24_PIPES) {

But when I change it the way above then my board will hang at startup.

What do you mean by that? What are the symptoms?

BTW, did you solve the issue with crashing of nrf24_rx_thread?

Marcin

from nrf24.

Yes, there is no crash anymore because Linux doesn't boot completely with that change.

from nrf24.

Console says "can't start journal service".. seems like the loop in rx_thread is executed intensively without waiting because NRF chip says that FIFO is not empty but "pipe" == 6 and as soon as I changed the condition there is no crash anymore and thread is executing the loop over and over.
I have no idea why NRF is returning 6 for pipe... That may mean a wrong configuration or the chip itself is broken. Here is my hardware https://www.aliexpress.com/item/Free-Shipping-NRF24L01-PA-LNA-Wireless-Module-with-Antenna-1000-Meters-Long-Distance-FZ0410-We-are/32834661886.html?spm=a2g0s.9042311.0.0.w9m9ec

from nrf24.

Comment out starting of rx and tx thread.

If your system boot up, try to read STATUS register via:
cat /sys/class/nrf0/status (or sth like that)

You will see if SPI communication with your module works. There should be output on the console and in dmesg.

Paste output here please.

Marcin

from nrf24.

root@aapi-bzdvwv:~# cat /sys/class/nrf24/nrf0/status
STATUS = 0x1C

dmesg says:

[ 100.133599] nrf24 spi32766.0: nrf24_print_status: CONFIG = 0xBC
[ 100.133688] nrf24 spi32766.0: nrf24_print_status: EN_AA = 0x54
[ 100.133747] nrf24 spi32766.0: nrf24_print_status: EN_RXADDR = 0x7E
[ 100.133801] nrf24 spi32766.0: nrf24_print_status: SETUP_AW = 0x06
[ 100.133852] nrf24 spi32766.0: nrf24_print_status: SETUP_RETR = 0xFD
[ 100.133904] nrf24 spi32766.0: nrf24_print_status: RF_CH = 0x04
[ 100.133955] nrf24 spi32766.0: nrf24_print_status: RF_SETUP = 0x28
[ 100.134007] nrf24 spi32766.0: nrf24_print_status: STATUS = 0x1C
[ 100.134058] nrf24 spi32766.0: nrf24_print_status: OBSERVE_TX = 0x00
[ 100.134109] nrf24 spi32766.0: nrf24_print_status: CD = 0x00
[ 100.134160] nrf24 spi32766.0: nrf24_print_status: FIFO_STATUS = 0x22
[ 100.134212] nrf24 spi32766.0: nrf24_print_status: DYNPD = 0x54
[ 100.134263] nrf24 spi32766.0: nrf24_print_status: FEATURE = 0x08

from nrf24.

Here interesting thing happens

root@aapi-bzdvwv:~# cat /sys/class/nrf24/nrf0/available_address_width
3 4 5

from nrf24.

I have one more question. Documentation says that NRF should respond with status byte first when you read any register. But in your code I can't see that you are skipping the 1st byte. Why ?

from nrf24.

Reading address width.
All good here. 3 4 5 means that you can configure module to use 3, 4 or 5 bytes long addresses.

Regarding STATUS register and 1st byte.
Registers are read using spi_w8r8 function which first writes 8 bits and then reads 8 bits while STATUS is being clocked out while first 8 bit are written. That is why it is skipped automatically.

Now, the most important, regarding values of STATUS and other registers. It looks that all your registers values read from module are shifted left by 1 bit.
Eg.:

• FEATURE is 0x08 while only EN_DPL bit is set and it should be 0x04
• RF_CH is 0x04 while 0x02 is the reset value.
• STATUS is 0x1C while it should be 0x0E.

That is the source of your problems. Not sure how to help you now...

from nrf24.

you are saying that all the registers shifted by 1 bit ?? how is that possible ?
why do you think this may happen ? is there a way to understand if this is a SPI driver issue or hardware issue ?

from nrf24.

Hard to say why it is like that. Try lowering your SPI frequency first to 1 MHz or even lower like 100 kHz and try then.

If if will not help, check spi mode config. I believe it should be SPI_MODE_0, but you could try different ones. There could be also some driver specific config missing. Really hard to guess.

from nrf24.

Here is STATUS request. Seems like hardware part is fine?

from nrf24.

Hmm, why clk is clocked out only 8 times? Is is write and then read or just read?

from nrf24.

This is only reading STATUS register. There is another byte following. Looks like master is sending 0x7 and then is staying at low level. Slave is responding with 0xE and again with 0xE. Both values are STATUS register.

from nrf24.

Here is the whole picture for reading STATUS register

from nrf24.

Yes, hardware part looks fine. 0x0E id "correct" value of STATUS register. It means that RX Fifo is empty.

And you confirm that your status is not 0x0E while displaying it in driver after that read you showed?

from nrf24.

The SPI driver gives me 0x1C. So the problem should be in sun6i SPI driver code.

from nrf24.

One more thing. Have you tried lowering SPI frequency? Screenshots you attached are form logic state analyzer and it does not show how plots actually looks like.

Give it a try with 1 MHz or lower.

Marcin

from nrf24.

I tried it, no difference. I did debugging in spi-sun6i.c and found something that looks too bad: readb function here http://elixir.free-electrons.com/linux/v4.13.12/source/drivers/spi/spi-sun6i.c#L155 returns already broken value... That seems like hardware issue.. but logic analyzer shows a good picture. I am really confused.

from nrf24.

I tried another device, OrangePi PC (Alwinner H3 Soc) and got with the same problem with SPI... that's so weird!

from nrf24.

Ok, I have tested communication using spi-gpio driver (bitbang/software spi emulation) and found that it is working fine.
[ 240.738204] nrf24 spi32766.0: nrf24_print_status: CONFIG = 0x0F
[ 240.738252] nrf24 spi32766.0: nrf24_print_status: EN_AA = 0x3F
[ 240.738296] nrf24 spi32766.0: nrf24_print_status: EN_RXADDR = 0x3F
[ 240.738339] nrf24 spi32766.0: nrf24_print_status: SETUP_AW = 0x03
[ 240.738382] nrf24 spi32766.0: nrf24_print_status: SETUP_RETR = 0xFF
[ 240.738426] nrf24 spi32766.0: nrf24_print_status: RF_CH = 0x02
[ 240.738468] nrf24 spi32766.0: nrf24_print_status: RF_SETUP = 0x07
[ 240.738511] nrf24 spi32766.0: nrf24_print_status: STATUS = 0x0E
[ 240.738554] nrf24 spi32766.0: nrf24_print_status: OBSERVE_TX = 0x00
[ 240.738597] nrf24 spi32766.0: nrf24_print_status: CD = 0x00
[ 240.738640] nrf24 spi32766.0: nrf24_print_status: FIFO_STATUS = 0x11
[ 240.738683] nrf24 spi32766.0: nrf24_print_status: DYNPD = 0x3F
[ 240.738727] nrf24 spi32766.0: nrf24_print_status: FEATURE = 0x04

from nrf24.

I am closing the issue as the problem described seems to be hardware-originated. Thanks for assistance.

from nrf24.