nRF240L01 with STM8L051F3

[Omi]

Hi, I am looking for procedure to make it work nRF240L01? I am getting documents for Arduino but as you know that is not understandable, with Arduino it worked but i don't understood. Now i want to make it work with STM8L051F3. STM8L051F3 is 8 bit ultra low power controller. I am looking for procedure like what steps i have to follow so i can send data to another nRF240L01. Which commands i have to send. I want to transmit data after every 1 sec and then it will go in power down. Receiver will be always in receiver mode.

[o.hojvat]

Thank yo very much for your reply

I will do exactly as the example you sent an inform results in about 2 days

I have well tested the SPI comunications , working OK

---------------------------------------------------------------

Level compatibility with 5VuP VCC.

 I have measured  CE  CSN  MOSI  and they are OK about input levels for uP   Vcc = 5V)

MISO output with 4K7  resistor to +5V  also has complete 0 an 5V range.

For  IRQ  similar resistor to +5V has no effect. I didn't find this information in data sheet

If uP has some problem with 3.3V as high level, I can reduce the Vcc supply to about 4V or add a small mosfet transistor as inverter (modifying as needed IRQ polarity definition)

Regards, Osvaldo

[ovrebekk]

Hi Osvaldo

Sorry for the slow response, I was out in Easter vacation until today. 

Are you still having issues with this? 

The nRF24L01+ will only work in the 1.9-3.6V range, and it is important that you keep the supply and the interface signals within this range. 

If you are unable to use an MCU that supports this level you will need some kind of level shifters on the signals, and a separate regulator for the nRF device to provide the supply voltage. 

Best regards
Torbjørn

[VE3ID]

ovrebekk said:

-- PTX -- 1) Set the PWR_UP bit in the CONFIG register 2) Set DYNPD to 0x3F 3) Set the EN_DPL bit in the FEATURE register 4) Upload a payload 5) Pulse CE for 10 us 6) Add a delay (1ms+) and repeat from 4) --PRX-- 1) Set the PWR_UP and PRIM_RX bits in the CONFIG register 2) Set DYNPD = 0x3F 3) Set the EN_DPL bit in the FEATURE register 4) Set CE high 5) Wait for the IRQ line to go low 6) Read out the RX payload 7) Repeat from 5)

Dear Torbjørn,

I just found this while seeking an answer to my own problem. I am programming  in C using an NXP FRDM-K64F dev kit which provides a handy socket just made for common modules using your chip.I have succeeded in getting TX to work and can see my packets going out on a sniffer, but never can get an RX packet to pull IRQ.  I just went through your notes and am doing exactly the same, except I am not setting up DPL. Should it still work or is DPL mandatory? 

[Håkon Alseth]

Hello,

 

VE3ID said:

I just found this while seeking an answer to my own problem. I am programming  in C using an NXP FRDM-K64F dev kit which provides a handy socket just made for common modules using your chip.I have succeeded in getting TX to work and can see my packets going out on a sniffer, but never can get an RX packet to pull IRQ.  I just went through your notes and am doing exactly the same, except I am not setting up DPL. Should it still work or is DPL mandatory? 

DPL is strictly not required, but you will need to have the same configuration on both PRX and PTX device.

So if one side is using static payload and the other is using dynamic payload; there will be mismatch.

 

Have you checked that bits 4:6 in CONFIG register is set to '0'?

If the nRF24L-series radio has its FIFO registers already filled up, it will stop reflecting IRQ - you can check the FIFO_STATUS to see if this has occurred.

 

Kind regards,

Håkon

[VE3ID]

God ettermiddag kjære Håkon,

(that's the limit of my Norwegian! :-) )

I set bits 4:6 in control at start of program, but clear them when I go to receive mode by writing 0x03 to the register.

I did get one packet received on the weekend (noticed by hitting a breakpoint in my handler code) after I added CRC to my TX, but it seems that it may have been caused by RX of a local thermostat!  Since then I cannot receive packets I am sending, but my sniffer tells me they are going out.

I have DPL disabled and am sending fixed length 32-byte packets.

All three MCUs have exactly the same code.

Not sure it can be a buffer full problem since is observed from reset, but will now write some code to check that.   

I should mention that my target app is an audio store-and-forward radio relay system that does not need most of the protocol you have built in to your chip - as it is basically a UDP network if I can steal a term from 802.03.

I have another question: I see you have a chip for 900 MHz ISM band, are you aware of any manufacturer that makes boards to evaluate it?  It is a commonly-used band here in Canada for ISM as well as amateurs, and my spectrum analyser only goes to 999 MHz so it would help me debug!

Tusen takk for your help. 

God tag,

Nigel

[Håkon Alseth]

Good morning Nigel,

 

VE3ID said:

God ettermiddag kjære Håkon,

(that's the limit of my Norwegian! :-) )

God ettermiddag!

I must say, you impress me with this greeting! :)

 

VE3ID said:

I set bits 4:6 in control at start of program, but clear them when I go to receive mode by writing 0x03 to the register.

This is good, this means that IRQ's shall be present on the nRF24L respective GPIO pins (if/when occurring)

 

VE3ID said:

I did get one packet received on the weekend (noticed by hitting a breakpoint in my handler code) after I added CRC to my TX, but it seems that it may have been caused by RX of a local thermostat!  Since then I cannot receive packets I am sending, but my sniffer tells me they are going out.

This can happen with wireless applications, especially if the CRC is weak (1 byte).

Since it was only one payload received over the timeframe of a weekend, I think we can safely assume that the communication is not quite up and running yet.

 

VE3ID said:

I should mention that my target app is an audio store-and-forward radio relay system that does not need most of the protocol you have built in to your chip - as it is basically a UDP network if I can steal a term from 802.03.

It sounds like you want to use the W_TX_PAYLOAD_NOACK feature?

This is set in the feature register, field EN_DYN_ACK:

If you are already using W_TX_PAYLOAD_NOACK and this bit isn't set, not much will happen.

If you still have issues, could you try to dump the registers of the nRF24L01+ (both on PRX and PTX) and share the content here?

 

PS: There is a "VDD_PA" signal on pin 11 which you can probe on your transmitter(s) - this will be high just before the transmission occurs on-air. If there's no pulses on this pin, the TX is not transmitting.

 

VE3ID said:

I have another question: I see you have a chip for 900 MHz ISM band, are you aware of any manufacturer that makes boards to evaluate it?  It is a commonly-used band here in Canada for ISM as well as amateurs, and my spectrum analyser only goes to 999 MHz so it would help me debug!

We do have this chip, but unfortunately we do not have modules. Our main focus the last 10-20 years has been on 2.4 GHz domain and the nRF905 / nRF9E5 has not been updated since they were released back in mid/late-00, so unfortunately there are not many modules officially available from us. However, I have seen cost-effective nRF905-modules available on sites like ebay/amazon/etc.

 

Kind regards,

Håkon

[o.hojvat]

Hi Nigel

from your comment:

I set bits 4:6 in control at start of program, but clear them when I go to receive mode by writing 0x03 to the register.

Please note that a t PRX you only need to activate (clear) bit 6 of config register

at start.   After any IRQ at PRX it must be cleared ( setting 1 ) bit 6 of status register

At PTX side , if PRX side fails receiving and there is not ack, at PTX, it TXfifo will be full in a short time (3 packets) and stop trasmiting.

Please try to flush TXFIFO at PTX before sending a new packet (command E1)

You also try to flush  RXFIFO at PTX to be sure that packet will be captured.

I have used at first tests a simple mode compatible with older model of 24L01 , no EN_AA in Reg 01 . Please see:

data sheet 77 , Appendix B - Configuration for compatibility with nRF24XX

Later I get all working with the suggestions of obrevekk, but using commands E1 and E2.

Regards, Osvaldo

[VE3ID]

Thank you, lots to think about.  But did you miss the comment I made that I am trying to UDP-like TX and RX, so I will not be looking for ack at any time.  It is for an audio RF linking system where the odd error is inconsequential.  All units have exactly the same image and their job is to receive a packet and pass it on to the next node without checking.

[Håkon Alseth]

Hi Nigel,

 

Did you look into the question that I posted?

Håkon Alseth said:

If you still have issues, could you try to dump the registers of the nRF24L01+ (both on PRX and PTX) and share the content here?

 

PS: There is a "VDD_PA" signal on pin 11 which you can probe on your transmitter(s) - this will be high just before the transmission occurs on-air. If there's no pulses on this pin, the TX is not transmitting.

Having the register dump from both your transmitter and receiver will greatly help in debugging what might be problematic.

 

Kind regards,

Håkon

[VE3ID]

Sorry for the tardiness, I have been tied up in maintenance in some other projects :-(

[MCUXpresso Semihosting Telnet console for 'Frere LinkServer Debug' started on port 57352 @ 127.0.0.1]


Sending init_String  

FF FF 20 7A 21 00 22 01 23 05 24 00 25 1E 26 06 2A E7 E7 E7 E7 
E7 2B E7 E7 E7 E7 E7 2C E7 2D E7 2E E7 2F E7 30 E7 E7 E7 E7 
E7 31 20 32 00 33 00 34 00 35 00 36 00 3D 01 

Dumping nRF24l01 registers

0x00 A8 C8 E8 08 28 48 68 88 A8 C8 E8 08 28 48 68 88 
0x10 A8 C8 E8 08 28 48 68 88 A8 C8 E8 08 28 

Transmitting Startup Announcement 
(On air, receipt confirmed by packet sniffer)

B0 46 72 65 72 65 20 52 61 64 69 6F 20 53 79 73 74 65 
6D 20 69 6E 69 74 20 56 45 33 49 44 0D 0A 07 FF 

In main loop  

Dumping nRF24l01 registers

0x00 A8 C8 E8 08 28 48 68 88 A8 C8 E8 08 28 48 68 88 
0x10 A8 C8 E8 08 28 48 68 88 A8 C8 E8 08 28 27

Entering Receive mode  

20 0F 27 40 27 20 27 10 

Dumping nRF24l01 registers

0x00 A8 C8 E8 08 28 48 68 88 A8 C8 E8 08 28 48 68 88 
0x10 A8 C8 E8 08 28 48 68 88 A8 C8 E8 08 28 17 

then so and so in a loop:

FF 17 FF 17 FF 17 FF 17 FF 17 FF 17 FF 17 FF 17 FF 17 FF 17 
FF 17 FF 17 FF 17 FF 17 FF 17 FF 

loops here looking for RX buffer full flag.

[Håkon Alseth]

Hi,

 

Initially your regs look like this:

addr + 0x20	content
20	7A
21	0
22	1
23	5
24	0
25	1E
26	6
2A	E7E7E7E7E7
2B	E7E7E7E7E7
2C	E7
2D	E7
2E	E7
2F	E7
30	E7E7E7E7E7
31	20
32	0
33	0
34	0
35	0
36	0
3D	1

 Here RX_ADDR_P0 is equal to RX_ADDR_P1, which is not allowed:

It does not matter if they are enabled or not, Pipe0 cannot be equal to Pipe1.

Are these the readback status register?

Dumping nRF24l01 registers

0x00 A8 C8 E8 08 28 48 68 88 A8 C8 E8 08 28 48 68 88 
0x10 A8 C8 E8 08 28 48 68 88 A8 C8 E8 08 28 17 

I am also a bit uncertain what this data is:

then so and so in a loop:

FF 17 FF 17 FF 17 FF 17 FF 17 FF 17 FF 17 FF 17 FF 17 FF 17 
FF 17 FF 17 FF 17 FF 17 FF 17 FF 

The STATUS register shall never return 0xFF. 

Kind regards,

Håkon

[VE3ID]

Tusen takk for all comments so far.  I have made changes suggested, but still no receive between two separatre units.  However I am getting a packet received indication in my code when I transmit from each unit in its own receiver. Is it expected that if PTX and PRX have same address a unit will lreceive its own packets?   This would indocate progress to me!