nRF5 action!

NeverDie

@NeverDie Thank you sharing your experience here. It helps me of better understanding some nRF5 internals. It would be awesome if you share your code.

Here it is:

#include <MySensors.h>
#include <nrf.h>

void setup() 
{
  NRF_POWER->DCDCEN=1;  //enable the DCDC voltage regulator as the default.

  //guarantee RESET pin is working
  if (((NRF_UICR-> PSELRESET[0])==0xFFFFFFFF) && ((NRF_UICR-> PSELRESET[1])==0xFFFFFFFF)) { //if the two RESET registers are erased
    NRF_NVMC->CONFIG=1;  // Write enable the UICR
    NRF_UICR-> PSELRESET[0]=21;  //designate pin P0.21 as the RESET pin
    NRF_UICR-> PSELRESET[1]=21;  //designate pin P0.21 as the RESET pin
    NRF_NVMC->CONFIG=0;  // Put the UICR back into read-only mode.
  }

  NRF_RADIO->FREQUENCY=123;
  NRF_RADIO->MODE=2;  //set 250kbps datarate.  May as well stretch out the NULL packet as much as possible.
  
  NRF_RADIO->TASKS_DISABLE=1;  //turn-off the radio to establish known state.
  while (NRF_RADIO->STATE!=0) {}  //busy-wait until radio is disabled
  NRF_RADIO->TASKS_TXEN=1;  //wake-up the radio
  while ((NRF_RADIO->STATE)!=10) {}  //busy-wait until radio has started TXIDLE
  
  //Assertion: radio is now in TXIDLE state.
}


void loop() {

    //assume radio is in TXIDLE state.
    NRF_RADIO->TASKS_START=1;  //Move from TXIDLE state to TX state.  This sends a NULL packet.
    while ((NRF_RADIO->STATE)!=11) {}  //busy-wait until radio is in TX state
    while ((NRF_RADIO->STATE)==11) {}  //busy-wait until radio is back to TXIDLE state
    //Assertion: radio is now back to TXIDLE state
 }

NeverDie

So, to make the above code work as a PPI, all I would need is some kind of linkage such that whenever the "event" of TXIDLE occurs, then a "task" (in this case it would be TASKS_START) is executed to move the radio back into the TX state.

Hmmm.. Still not obvious though from just the datasheet how to actually setup even that simple linkage.

d00616

@NeverDie said in nRF5 Bluetooth action!:

So, to make the above code work as a PPI, all I would need is some kind of linkage such that whenever the "event" of TXIDLE occurs, then a "task" (in this case it would be TASKS_START) is executed to move the radio back into the TX state.

This is a use case for shortcuts. PPI is not required.

There is no TXIDLE event but looking at the state diagram is TXIDLE a result of ether READY or END event. You can enable following shortcurts:

NRF_RADIO->SHORTS = RADIO_SHORTS_READY_START_Msk | RADIO_SHORTS_END_START_Msk;

In PPI this should be the code (untested):

#define CHANNEL (1)
NRF_PPI->CH[CHANNEL].EEP = (uint32_t)&NRF_RADIO->EVENTS_END;
NRF_PPI->CH[CHANNEL].TEP = (uint32_t)&NRF_RADIO->TASKS_START;
NRF_PPI->CH[CHANNEL+1].EEP = (uint32_t)&NRF_RADIO->EVENTS_READY;
NRF_PPI->CH[CHANNEL]+1.TEP = (uint32_t)&NRF_RADIO->TASKS_START;
NRF_PPI->CHENSET = (1 << CHANNEL) | (1 <<( CHANNEL+1));

NeverDie

Thanks! That helps my understanding quite a bit. I've tested the following shortcut code, and it works:


#include <MySensors.h>
#include <nrf.h>

void setup() 
{
  NRF_POWER->DCDCEN=1;  //enable the DCDC voltage regulator as the default.

  //guarantee RESET pin is working
  if (((NRF_UICR-> PSELRESET[0])==0xFFFFFFFF) && ((NRF_UICR-> PSELRESET[1])==0xFFFFFFFF)) { //if the two RESET registers are erased
    NRF_NVMC->CONFIG=1;  // Write enable the UICR
    NRF_UICR-> PSELRESET[0]=21;  //designate pin P0.21 as the RESET pin
    NRF_UICR-> PSELRESET[1]=21;  //designate pin P0.21 as the RESET pin
    NRF_NVMC->CONFIG=0;  // Put the UICR back into read-only mode.
  }

  NRF_RADIO->FREQUENCY=123;
  NRF_RADIO->MODE=2;  //set 250kbps datarate.  May as well stretch out the NULL packet as much as possible.
  
  NRF_RADIO->TASKS_DISABLE=1;  //turn-off the radio to establish known state.
  while (NRF_RADIO->STATE!=0) {}  //busy-wait until radio is disabled
  NRF_RADIO->SHORTS = B100001;  //Implement shortcuts: READY_START and END_START
  NRF_RADIO->TASKS_TXEN=1;  //wake-up the radio transmitter and move it into state TXIDLE.

  //The shortcuts will take-over the moment the state TXIDLE becomes activated.
}


void loop() {

}

NeverDie

Is there any example code which illustrates the use of interrupts on the nRF52832?

NeverDie

Looks as though it should be possible to send tightly packed meaningful packets, not just null packets, using almost the same methodology.

d00616

@NeverDie said in nRF5 Bluetooth action!:

Is there any example code which illustrates the use of interrupts on the nRF52832?

Yes. In a sketch, you have to put the interrupt routine into one line. You can define the interrupt only once. If you want to use the radio ISR, you can't enable the radio in MySensors.

https://github.com/sandeepmistry/arduino-nRF5/issues/52

https://github.com/mysensors/MySensors/blob/development/drivers/NRF5/Radio_ESB.cpp#L500

NeverDie

Interestingly enough, it turns out all I need to do is transmit one packet, and afterward just leave the radio in TXIDLE mode. That's because, as indicated in the datasheet, it transmits a carrier wave of one's (or any pattern you program) after the packet, expecting that another packet will be sent soon. This is illustrated in Figure 37 of the DS.

NeverDie

So, I've got the transmit side of this problem figured out. Next up: the receiver side, which already works using the MCU.
The next step will be to see whether I can setup timed events from the RTC which can be used to trigger the PPI to measure the RSSI without waking up the MCU. Also, I'll need some way for the PPI to evaluate the magnitude of the RSSI without involving the MCU. Ideally it would also trigger a Rx sequence if the RSSI is above threshold and wake the MCU if something gets received. Not sure how much of this will be possible, but that's the wish list.

I'd say the energy consumption is already pretty good after switching to the RSSI paradigm, but if this succeeds, then it may cut what remains of the energy consumption roughly in half. At that point, I think we will have wrung just about every possible bit of efficiency out of this radio, with the remaining to-do's as mostly mop-up and maybe some fine tuning (e.g. to better mitigate against false positives on the RSSI threshhold trigger).

NeverDie

So, I figure the way to get started is to do something "easy", like maybe use the PPI to blink an LED.

We want the lower power RTC, not the system clock. We want to use the RTC TICK event, so that the mpu can be powered down while the PPI is running.

So, because I want a timer event every 100ms, that means the prescaler should be 3276.

NeverDie

So, just starting on this, where I'm at is:

#include <nrf.h>
#include <MySensors.h>


#define LED_PIN 18

bool toggle=false;  //track whether or not to toggle the LED pin

void setup() {
  NRF_CLOCK->LFCLKSRC=1;  //use the crystal oscillator.
  NRF_CLOCK->TASKS_LFCLKSTART=1;  //start the crystal oscillator clock
  while (!(NRF_CLOCK->EVENTS_LFCLKSTARTED)) {}  //busy-wait until the clock is confirmed started.

  NRF_RTC1->TASKS_STOP=1;  //stop the RTC so that we can set the prescaler
  NRF_RTC1->PRESCALER=3276;  //once per 100ms
  NRF_RTC1->TASKS_START=1;  //start the RTC so that we can start getting TICK events

  hwPinMode(LED_PIN,OUTPUT_H0H1);  //establish P0.18 as the LED pin.
}

void loop() {
  if (NRF_RTC1->EVENTS_TICK) {
    toggle=!toggle;
    digitalWrite(LED_PIN,toggle);
  }
}

Unfortunately, this does not work because (NRF_RTC1->EVENTS_TICK) always reads as zero. Not sure why(?).

Jokgi

@NeverDie you will need long range capabilities on both sides of the link. So two preview kits work great. Long range is supported by SDK 14 and the current softdevice.

Jokgi

@scalz the nRF52832 has a hotter receiver. ( better sensitivity.) at 1 mb/ s then the nRF24l series. Overall link Budget is better. 840 even better with a 8dB output.

scalz

@Jokgi
of course I agree !
that's why in the past i preferred rfm69 modules (better range of course, but more power hungry). 832 being better than nrf24, i'm now using it. And I also like the 840dk (neat package) :+1:
That said, if i remember well, nrf52832 is not fully BLE5 long range compatible as 840 is.

NeverDie

@Jokgi said in nRF5 Bluetooth action!:

@NeverDie you will need long range capabilities on both sides of the link. So two preview kits work great. Long range is supported by SDK 14 and the current softdevice.

I'm not disagreeing, but presently modules for it (other than the preview DK) aren't yet available. Meanwhile, hopefully nearly all of what's being learned here about the nRF52832 will be of direct relevance. For instance: PPI.

NeverDie

@NeverDie said in nRF5 Bluetooth action!:

Unfortunately, this does not work because (NRF_RTC1->EVENTS_TICK) always reads as zero. Not sure why(?).

It should be working, but it isn't. Nor do I see a way to check it with an oscilliscope. So, my current theory is that it gets set but cleared so quickly that it can't be read by the MCU. So, the next step will be to assume that it is, in fact, working, and to use it as a PPI trigger, which is what this is all building toward anyway.

On the other hand, perhaps there's an easy way to have the EVENTS_TICK set an interrupt bit, which would persist until it was cleared? Hmmm. No, not quite, but there is INTENSET, which will set an interrupt on an EVENT_TICK. That will do. Exactly which interrupt gets triggered though? Figure 46 shows that an IRQ signal is sent to NVIC ( the Nested Vectored Interrupt Controller). According to the table in sectoin 7.3, the NVIC has 37 interrupt vectors. According to section 15.8:

A peripheral only occupies one interrupt, and the interrupt number follows the peripheral ID. For example, the
peripheral with ID=4 is connected to interrupt number 4 in the Nested Vectored Interrupt Controller (NVIC).

So, based on that, we need to know the ID number for the RTC, and then we'll know which interrupt number to track. According to Table 10, the Peripheral ID for the RTC is 11 (well, at least it is for the RTC0, so I will recode to use RTC0 instead of RTC1).

Now, according to Table 10, the memory location that corresponds to Peripheral ID 11 is 0x4000B000. Therefore, it is this memory location we need to examine to know if a TICK interrupt has occured.

NeverDie

Close, but no cigar. What I found out is that if I set the TICK interrupt with:

      NRF_RTC0->INTENSET=1;  //set the TICK interrupt bit

then at the following memory addresses, the value stored there immediately becomes 1:
4000B300
4000B304
4000B308

and if I clear the TICK interrupt with:

      NRF_RTC0->INTENCLR=1;  //clear the TICK interrupt bit

then the values at those same memory addresses immediately becomes zero. I can toggle back and forth as much as I want, and this is always true.

However, none of this is telling me whether the TICK interrupt has actually triggered. Where do I find that?

Based on the current pre-scaler, COUNTER increments once every TICK (i.e. once every 100ms). However, is there an actual TICK flag somewhere that goes high at those times and then low again after getting cleared? Or, is it only accessible indirectly by using PPI?

NeverDie

OK, I came up with a simple equivalent. Basically, every time COUNTER is incremented, I reset it to zero. It then effectively acts much the way a TICK should. For whatever reason, once EVENTS_TICK goes high, it just stays high forever. So, it doesn't seem very useful per se, though maybe there's a way to clear it that I haven't yet found.

NeverDie

Strangely enough, the overflow is the same: once it goes HIGH, it stays that way:
https://pastebin.com/vypuVJeh

So, I would think there must be some way (?) to clear them.

NeverDie

I found the answer. Unlike EVENTS in other peripherals, which are read-only, the EVENTS in RTC are RW. So, the way you clear the TICK and OVRFLW events is just by setting them to zero manually:
e.g.

NRF_RTC0->EVENTS_TICK=0;

LOL. Of course, the DS never mentions this.

In any case, with that change, it can now work properly:
https://pastebin.com/nHWAGFkd

nRF5 action!

9

11.7k

11.2k

113.0k