nRF240L01 with STM8L051F3

RE: nRF240L01 with STM8L051F3

Håkon Alseth — Fri, 14 Mar 2025 08:31:08 GMT

Hi Nigel,

[quote user="VE3ID"]That has fixed that problem. Now I just have to undo all the changes I made in troubleshooting and trying to fix that myself! [/quote]

That is great news! I am so glad to hear that you've found a solution!

[quote user="VE3ID"]To be honest, I have great difficulty reading the state diagram (my eyes are 71 years old :-) with very faint graphics on white background. Perhaps you have another hi-res copy that is not embedded in another document to send me to avoid me leaning on you for your kind advice :-)[/quote]

My apologies for only sharing a picture. I agree that a white background is not easy on the eyes, especially since computer screens are so bright.

Here is the link to the .pdf, which you can store locally:

https://docs.nordicsemi.com/bundle/nRF24L01P_PS_v1.0/resource/nRF24L01P_PS_v1.0.pdf

This includes vectorised graphics, so you should be able to zoom without any reduction in quality.

The diagram which I previously shared is on page 35 of this document.

[quote user="VE3ID"]Yes, that is a problem I am also seeing. My packet sniffer says the packets are going out on the air, but after three transmit sessions I can send no more, indicating that they are not being cleared, despite sending the clear code for RX and TX! After making the changes to CSN I am now getting a status of 0x01 which confirms that.[/quote]

This is good to hear! There are several notes in the datasheet that is easy to miss, but having worked with this device for years-and-years, we at support know most of its caveats :-)

Let me know if you run into any issues or have questions, Nigel. I wish you a wonderful weekend!

Kind regards,

Håkon

RE: nRF240L01 with STM8L051F3

VE3ID — Thu, 13 Mar 2025 16:11:55 GMT

[quote userid="2115" url="~/f/nordic-q-a/28621/nrf240l01-with-stm8l051f3/526757"]What is a bit strange here is that you upload one payload, but the STATUS register returns 0x0F for the remainder of the period, indicating that the TX_FIFO is filled up. Was there any payloads uploaded prior to this trace?[/quote]

Yes, that is a problem I am also seeing. My packet sniffer says the packets are going out on the air, but after three transmit sessions I can send no more, indicating that they are not being cleared, despite sending the clear code for RX and TX! After making the changes to CSN I am now getting a status of 0x01 which confirms that.

RE: nRF240L01 with STM8L051F3

VE3ID — Thu, 13 Mar 2025 14:00:00 GMT

Tusen takk, Håkon,

That has fixed that problem. Now I just have to undo all the changes I made in troubleshooting and trying to fix that myself! To be honest, I have great difficulty reading the state diagram (my eyes are 71 years old :-) with very faint graphics on white background. Perhaps you have another hi-res copy that is not embedded in another document to send me to avoid me leaning on you for your kind advice :-)

RE: nRF240L01 with STM8L051F3

Håkon Alseth — Tue, 11 Mar 2025 13:06:20 GMT

Hi,

Thank you for the traces.

It seems that the device reports back "0x0F" on MISO to each command (0xFF / 0x07), and this does not change throughout the trace itself.

The CE pin is set high before the payload is uploaded, which is fine, but has its drawbacks, as CSN is also never set high (ie. idle) between each poll. Try setting the CSN pin idle between each poll.

This is required when CE=1, as shown in the ps chapter 6.1.6:

If CE is held high all TX FIFOs are emptied and all necessary ACK and possible retransmits are carried out. The transmission continues as long as the TX FIFO is refilled. If the TX FIFO is empty when
the CE is still high, nRF24L01+ enters standby-II mode. In this mode the transmission of a packet is
started as soon as the CSN is set high after an upload (UL) of a packet to TX FIFO.

What is a bit strange here is that you upload one payload, but the STATUS register returns 0x0F for the remainder of the period, indicating that the TX_FIFO is filled up. Was there any payloads uploaded prior to this trace?

Kind regards,

Håkon

RE: nRF240L01 with STM8L051F3

VE3ID — Mon, 10 Mar 2025 16:21:21 GMT

Tusen takk, Håkon,

Let's try this...devzone.nordicsemi.com/.../Sample_5F00_for_5F00_nordsemi.tar.gz

RE: nRF240L01 with STM8L051F3

Håkon Alseth — Mon, 10 Mar 2025 08:17:03 GMT

Hi Nigel,

PulseView is not a problem.

[quote user="VE3ID"]I tried to upload the srzip output in case you can read it, but it would not let me[/quote]

Unfortunately, the web engine is a bit restrictive in terms of file extensions. If you archive the file (tar, gz, bz, zip, rar, etc), you should be able to select and upload your file.

Kind regards,

Håkon

RE: nRF240L01 with STM8L051F3

VE3ID — Fri, 07 Mar 2025 18:53:45 GMT

I tried to upload the srzip output in case you can read it, but it would not let me :-( Thanks, Nigel

RE: nRF240L01 with STM8L051F3

VE3ID — Fri, 07 Mar 2025 16:27:17 GMT

Thank you. The graphic would be pretty big, but my analyser is Pulseview and its output can go to srzip session file format data files, can you read those?

RE: nRF240L01 with STM8L051F3

Håkon Alseth — Fri, 07 Mar 2025 14:50:40 GMT

Hi,

TX_DS should occur quickly, especially when using "W_TX_PAYLOAD_NO
ACK", as shown in the PS chapter 7.5.1:

If you have a stored logic trace of the SPI communication, I would be happy to have a look.

Kind regards,

Håkon

RE: nRF240L01 with STM8L051F3

VE3ID — Fri, 07 Mar 2025 12:55:49 GMT

Thanks to all for the help I have had so far. I am now able to send and receive complete packets, however, there is a terrible intermittency in my reading the status register to see if a packet has been sent out, sometimes it hangs on the <send 0x07> <listen for status including TX_DS> loop for many seconds! I will try and include graphic of logic analyser.

RE: nRF240L01 with STM8L051F3

Håkon Alseth — Thu, 06 Feb 2025 15:28:08 GMT

Hi,

Are you certain that you are using this command?

That should be cmd=0xB0.

[quote user="VE3ID"]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![/quote]

Which event do you receive specifically here? If "NOACK" is used, a STATUS::TX_DS shall be set.

Kind regards,

Håkon

RE: nRF240L01 with STM8L051F3

VE3ID — Wed, 05 Feb 2025 16:03:04 GMT

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!

RE: nRF240L01 with STM8L051F3

Håkon Alseth — Thu, 30 Jan 2025 10:12:08 GMT

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

RE: nRF240L01 with STM8L051F3

VE3ID — Tue, 28 Jan 2025 18:15:11 GMT

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.

RE: nRF240L01 with STM8L051F3

Håkon Alseth — Wed, 22 Jan 2025 14:45:56 GMT

Hi Nigel,

Did you look into the question that I posted?

[quote user="hkn"]

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.

[/quote]

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

Kind regards,

Håkon

RE: nRF240L01 with STM8L051F3

VE3ID — Tue, 21 Jan 2025 19:57:33 GMT

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.

RE: nRF240L01 with STM8L051F3

o.hojvat — Tue, 21 Jan 2025 19:48:23 GMT

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

RE: nRF240L01 with STM8L051F3

Håkon Alseth — Mon, 20 Jan 2025 16:10:21 GMT

Good morning Nigel,

[quote user="VE3ID"]

God ettermiddag kjære Håkon,

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

[/quote]

God ettermiddag!

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

[quote user="VE3ID"]

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.

[/quote]

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

[quote user="VE3ID"]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.[/quote]

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.

[quote user="VE3ID"]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.[/quote]

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?

[quote user="VE3ID"]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![/quote]

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

RE: nRF240L01 with STM8L051F3

VE3ID — Mon, 20 Jan 2025 14:25:10 GMT

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

RE: nRF240L01 with STM8L051F3

Håkon Alseth — Mon, 20 Jan 2025 08:24:42 GMT

Hello,

[quote user="VE3ID"]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? [/quote]

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

RE: nRF240L01 with STM8L051F3

VE3ID — Fri, 17 Jan 2025 16:37:07 GMT

[quote userid="2116" url="~/f/nordic-q-a/28621/nrf240l01-with-stm8l051f3/113446"]-- 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) [/quote]

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?

RE: nRF240L01 with STM8L051F3

ovrebekk — Fri, 14 Apr 2023 06:53:05 GMT

Hi Osvaldo

[quote user="o.hojvat"]In other case, with 5V supply, MOSI, CLK, CE, CSN are input with no clipping and tolerating 5V[/quote]

You mean the nRF24L01+ appears to work fine even if you apply 5V on the signal lines?

I would strongly discourage this if you are planning to go to production with this project. Using the part outside the specified operating range means you could have unpredictable issues down the line, and there is a higher risk that devices will stop working in the field even if they might work on your desk.

[quote user="o.hojvat"]After a carefull revision of soft and hardware, I will test and inform you about it[/quote]

Sounds like a plan. Good luck 🙂

Best regards
Torbjørn

RE: nRF240L01 with STM8L051F3

o.hojvat — Thu, 13 Apr 2023 05:41:10 GMT

I was working on other matters for a week and now comeback with NRF24L01+

Thank you for your suggestions. In one case I can use a processor with 3,6V so no level problem

In other case, with 5V supply, MOSI, CLK, CE, CSN are input with no clipping and tolerating 5V

MISO seems to be open drain and with 4K7 resistor to+5V is OK for procesor SPI data input.

A similar resistor at IRQ has not any usefull level correction, but I wil place an small mosfet (2N7002)

and 4k7 drain to +5V resistor as inverter. Procesor interrupt input to be set as active for low to high transition

I am writing a new assembler following your mentioned steps.

After a carefull revision of soft and hardware, I will test and inform you about it

Regards, Osvaldo

RE: nRF240L01 with STM8L051F3

ovrebekk — Tue, 11 Apr 2023 10:38:07 GMT

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

RE: nRF240L01 with STM8L051F3

o.hojvat — Fri, 31 Mar 2023 17:56:23 GMT

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