NRF24LE1 Communication

RE: NRF24LE1 Communication

ovrebekk — Wed, 02 May 2018 11:55:05 GMT

How do you define the tx_address and rx_address variables?

Do you know if they are located in data, xdata or code memory?

Best regards
Torbjørn

RE: NRF24LE1 Communication

ozo.m — Sat, 28 Apr 2018 19:02:39 GMT

Hello! It's been a while but slow and steady I have almost produced the system I need.

But I have encountered a problem I can't overcome. My simple system works just fine as long as I have on pair of nrf24le1's as they use the default address. Problem is, I need several pairs working in close range, therefore I want to set address for each pair of nrf's I need.

When I use the lines: hal_nrf_set_address(HAL_NRF_TX, tx_address) and hal_nrf_set_address(HAL_NRF_PIPE0, rx_address); in my code, Keil compiler shows: "warning C196: mspace probably invalid" when compiling

What am I doing wrong? Any suggestions?

RE: NRF24LE1 Communication

ozo.m — Tue, 26 Sep 2017 10:45:34 GMT

// Global variables uint8_t payload[3];

void main()
{
	// Open GPIO latches in case they were previously locked.
  
OPMCON = 0x00;
	
#ifdef MCU_NRF24LE1
  while(hal_clk_get_16m_source() != HAL_CLK_XOSC16M)
  {
    // Wait until 16 MHz crystal oscillator is running
  }
#endif
  
  #ifdef MCU_NRF24LU1P
  // Enable radio SPI
  RFCTL = 0x10;
  #endif

	P0CON = 0x70; // Disable digital input buffer, pin used for 32kHz.
	P0CON = 0x71; // Disable digital input buffer, pin used for 32kHz.
  //P0CON = 0x76;    // P06 must not be disconnected as it is required to wake up the nRF24LE1 

  // Set P0.6 as input for wake up, others as output
  
P0DIR = 0x40;

  // Enable the radio clock
  RFCKEN = 1; 

	hal_rtc_start(false);
	hal_clklf_set_source(HAL_CLKLF_XOSC32K); 
	hal_rtc_set_compare_mode(HAL_RTC_COMPARE_MODE_0);
	hal_rtc_set_compare_value(0x7FFF);
	hal_rtc_start(true);

	// Wait for the 32kHz to startup (change phase)
	while((CLKLFCTRL&0x80)==0x80);
	while((CLKLFCTRL&0x80)!=0x80);
	
  // Enable RF interrupt
  RF = 1;
  
// Enable global interrupt
  EA = 1;
	
IEN1 = 0x08;

  // Configure radio as primary receiver (PRX)
  hal_nrf_set_operation_mode(HAL_NRF_PRX);

  // Set payload width to 3 bytes
  hal_nrf_set_rx_payload_width((int)HAL_NRF_PIPE0, 3);

  // Power up radio
  hal_nrf_set_power_mode(HAL_NRF_PWR_UP);

  // Enable receiver
  CE_HIGH();

  for(;;)
	
{
		// Wake up on pin P0.6
		
WUOPC0 = 0x40;
		// Inverse wakeup on pin polarity on selected GPIO's (P06 on 24-pin LE1. P06, P12 and P14 on 32-pin LE1. P22 and P26 on 48-pin LE1).
    
OPMCON |= 0x04;
		
// Lock GPIO latches. 
    
OPMCON |= 0x02;
		
// Register retention mode
		
PWRDWN = 0x04;
		
// Standby mode (wait for interrupt)
		
PWRDWN = 0x07;
		
// Clear PWRDWN
		
PWRDWN = 0x00;
		
// Continue to run code
		
P03 = !P03; 
	};
}

void wakeup_tick() interrupt INTERRUPT_TICK
{
P02 = !P02;
}

// Radio interrupt
NRF_ISR()
{
  uint8_t irq_flags;

  // Read and clear IRQ flags from radio
  irq_flags = hal_nrf_get_clear_irq_flags();

  // If data received
  if((irq_flags & (1<<(uint8_t)HAL_NRF_RX_DR)) > 0)
  {
    
// Read payload
    while(!hal_nrf_rx_fifo_empty())
    {
      hal_nrf_read_rx_payload(payload);
    }

    
// Write received payload[0] to port 0
    P0 = payload[0];
  }
}

/** @} */

RE: NRF24LE1 Communication

ozo.m — Tue, 26 Sep 2017 10:45:22 GMT

Hello! :) So I've been experimenting with the Nordic's given example codes and codes I could find on the internet. From 0 knowledge in this I have went to at least some knowledge in all this. I have been trying to merge the ESB(PRX) example code and the "Register retention, timers on" and WUOP funstion examples, but it does not seem to working. When I switch on the PRX, LED's just light up and there is no reaction when I put pins to GND on PRX and PTX modules. The setup is PRX connected to 3.3V, GND and P04, P05 to LED's. On the PTX side, 3.3V, GND and P04, P05 to buttons. I will attach the code I've been trying to get working. I would greatly appreciate if you could take a look and see what might be the problem. Thank you for any tips and suggestions!

RE: NRF24LE1 Communication

ovrebekk — Thu, 24 Aug 2017 12:41:50 GMT

Hi
These are independent mechanisms and can be enabled separately. There are separate interrupt handlers for the two wakeup sources that will fire, depending on what woke you up.
In other words you shouldn't have to change any of the existing code to add the wakeup on pin functionality.
Best regards

RE: NRF24LE1 Communication

ozo.m — Tue, 22 Aug 2017 18:55:47 GMT

In connection with the TX module setup, the RX module would be programmed in RTC mode and ESB_prx. When going through the question section I saw a post where you uploaded an example where you modified the ESB TX example to use RTC sleep. I see the difference between the orig. ESB TX example. The problem is that I don't really understand how the WUOPC0/1 works with the RTC sleep. In the example codes for RTC I see that there is "wakeup_tick". Does that part of the code needs to be changed to WUOPC0/1 or the "wakeup_tick" remains and WUOPC0/1 is added? Thank you for you patience with me. Many thanks, M

RE: NRF24LE1 Communication

ozo.m — Tue, 22 Aug 2017 18:55:36 GMT

Thank you for the suggestion! :) I assume that a 3uA power consumption would be okay, even if the RX module would be switched on for approx. 16 h a day. I hope it's okay that I write another question for you here. Power consumption on the TX module is not very relevant as it would be connected to an appliance which would switch the module on maybe just a few times a week. According to that I assume I can use the ESB_ptx example to program it, make f.e. pin 0.6 as active low and by switch on it should trigger the RX module to wake it up if the pin 0.6 is set for WUOPC0?

RE: NRF24LE1 Communication

ovrebekk — Tue, 22 Aug 2017 14:22:31 GMT

I am glad to hear it made more sense now :)
Depending on the wakeup interval you might want to consider 'register retention' mode also. The sleep current is a bit higher (~3uA), but you don't have to reset the MCU for each wakeup. This means that you spend less time re-configuring all the interfaces and modules, which speeds up wake up and might simplify code development (in register retention the code will continue running where it left off, rather than starting from the top).
Best regards

RE: NRF24LE1 Communication

ozo.m — Mon, 21 Aug 2017 16:00:43 GMT

After your response I now understand this better. At first I thought that I could program the RX to wake up on pin, set some pins as active low on the TX side but that's not how it works as the RX won't look for the packets in deep sleep mode. I assume I could just leave the RX chip in active mode and let it look for packets from the TX all the time but that would cause a serious power consumption. After looking at the Power cons. in Product spec. I understand that the "memory retention timers on" mode would fit best and provide a low power consumption even if I'd program the RX chip to wake up every 3 seconds. I'll try to examine that mode and hope I'll get somewhere. Thank you again for the help!

RE: NRF24LE1 Communication

ozo.m — Mon, 21 Aug 2017 16:00:22 GMT

Thank you for the thorough response! Fortunately I was able to program them again and they are working just fine. I had some wiring issues on the breadboard that caused the chip to warm up but that's fixed. Your given example works good, I managed to enter deep sleep and wake up on pin.

RE: NRF24LE1 Communication

ovrebekk — Mon, 21 Aug 2017 11:45:56 GMT

What do you mean about nearly burning the chips? That you were unable to program them again?

I wrote a small example many years ago, showing how to implement wakeup on pin from deep sleep: Wakeup on pin.zip
Maybe you could take a look at that and see if you handle power management in the same way?

Also, please be aware that you can't use the radio in deep sleep mode. If you want to wake up the chip through the radio you have to simulate it by waking up periodically and turning on the RX for a short amount of time to look for packets, and then you can go to sleep in between RX periods. If you want to sleep on a timer then the lowest mode you can use is 'memory retention timers on'.

Best regards
Torbjørn