nRF5 action!

[d00616]

@NeverDie said in nRF5 Bluetooth action!:

Actually, even just sleeping the MCU with a simple command like:
sleep(100);

is apparently enough to require a re-init of the radio afterward. Not sure why that would be.

sleep() deinitializes the transport with transportDisable(). This results in power down the radio.

At the moment I review the ESB code. I think the nRF5 is 12-13µs after an nRF24 in RX mode and 432µs before an nRF24 in TX. This can result in unstable connections when debug messages are disabled.

[NeverDie]

Sort-of working. Here's a screen shot with the DC/DC modification. Compare to the earlier one above:

Probably non-optimal placement of the inductors: between the DCC and DEC4 pins on my breakout board for the nRF52832.

This is reason enough to do an new version of the breakout for the Ebyte module to improve the inductor positioning.

Here's the enable code:

  NRF_POWER->DCDCEN=1;  //enable the DCDC voltage regulator as the default.

If it's this easy, I'm just surprised that the module makers haven't included it. The difference in build cost is de minimus, but the difference in delivered value is huge.

Also, it sounds like I'll have to write a variant of sleep that sleeps just the MPU while leaving the radio in receive mode. That's an easy win to improve the current consumption.

[NeverDie]

Good news! I went back and re-rechecked using an un-modified Ebyte module, and, indeed, this time I'm sure that the DCDC inductors are already on it! What follows is the proof. Here is the current drawn when the above DCDCEN is enabled on an unmodified Ebyte module:

Now, here is the current drawn with the exact same script on the exact same unmodified Ebyte module, but with the DCDCEN line of code commented out:

QED.

As you can see, the savings in current consumption are considerable with the DCDC enabled!

[Edit: although looking at it again, the timescale seems way off. Argh. Something still isn't right.]

[NeverDie]

Scratch the preceeding post. I redid it more carefully this time, and I believe it confirms that the Ebyte module does not have the two inductors required for DC/DC mode.

Here is the current drawn by an unmodified Ebyte nRF52832 module which is programmed to be receiving for about 1.5ms every 100ms:

[NeverDie]

Here is what happens with exactly the same hardware (no inductors yet added), but with DCDCEN enabled:

It basically seems caught in a boot loop.

[NeverDie]

Now, adding the two inductors between DCC and DEC4, and re-measuring, we get:

No less importantly, it does receive and decode packets!

Conclusion: Ebyte nRF52832 modules don't come with the DC/DC inductors already installed. However, they can be added, resulting in some current reduction.

[NeverDie]

I've baked these findings into a new breakout board for the Ebyte nRF52832:
https://www.openhardware.io/view/471
The new breakout board will enable the module to work in DC/DC mode.

[NeverDie]

I may have found a clue as to why the reset pin (pin0.21) on the nRF52832 isn't working.

On the nRF52832 DK, I read the following register values:
PSELRESET[0]=21
PSELRESET[1]=21

which is as expected. However, on the Ebyte nRF52832 module, I read those register values as:
PSELRESET[0]=4294967295
PSELRESET[1]=4294967295

which makes no sense. The values match, but they don't correspond to a pin number that can represent RESET.

These two registers are described in the nRF52832 datasheet.

[mfalkvidd]

@NeverDie not sure if you've already noticed, but 4294967295 is the maximum value for an unsigned 32-bit integer. So the value is 0xFFFFFFFF. That often means uninitialized. I don't know why it would be uninitialized though.

[NeverDie]

@mfalkvidd

Maybe because they just never were?
Those particular registers are "The user information configuration registers (UICRs) are non-volatile memory (NVM) registers for configuring user specific settings." So, it would seem that initializing them just once would be enough, since they're non-volatile.

In any case, good catch! It explains both why they are that value and also why they match.

[NeverDie]

@NeverDie said in nRF5 Bluetooth action!:

4294967295

Also, since 4294967295 equals 0xFFFFFFFF, then bit 31 is a '1', which, according to the datasheet, means the pin is disconnected (see section 14.1.60 PSELRESET[0] of the datasheet for the detail].

[NeverDie]

@mfalkvidd said in nRF5 Bluetooth action!:

So the value is 0xFFFFFFFF. That often means uninitialized. I don't know why it would be uninitialized though.

There's a chance we may have unwittingly done it ourselves! Remember back to when we were doing an explicit "Erase All"? From the datasheet:

11.5 Erase all
When erase is enabled, the whole Flash and UICR can be erased in one operation by using the ERASEALL
register.

Furthermore, from page 29 of the datasheet:

After erasing UICR all bits in UICR are set to '1'.

[d00616]

@NeverDie said in nRF5 Bluetooth action!:

@mfalkvidd said in nRF5 Bluetooth action!:

So the value is 0xFFFFFFFF. That often means uninitialized. I don't know why it would be uninitialized though.

There's a chance we may have unwittingly done it ourselves! Remember back to when we were doing an explicit "Erase All"? From the datasheet:

This is part of the arduino-nrf5 code -> https://github.com/sandeepmistry/arduino-nRF5/blob/dc53980c8bac27898fca90d8ecb268e11111edc1/cores/nRF5/SDK/components/toolchain/system_nrf52.c#L156

I don't have any idea why this is not included in the binary. When the reset menu is selected then "-DCONFIG_GPIO_AS_PINRESET" is given to gcc.

When system_nrf52.c is completely ignored, then the erratas are not handled.

[NeverDie]

Here is some verbose code which properly sets the registers to use pin P0.21 as the RESET pin:

Serial.println("Testing...");
delay(10000);  //give preparation time to open serial tty
Serial.print(counter);
Serial.print(", PSELRESET[0]=");
Serial.println(NRF_UICR-> PSELRESET[0]);
Serial.print(counter++);
Serial.print(", PSELRESET[1]=");
Serial.println(NRF_UICR-> PSELRESET[1]);

Serial.println();
Serial.println("Write-enabling CONFIG.");
NRF_NVMC->CONFIG=1;  // Write enable the UICR

Serial.println();
Serial.println("Now designating pin pO.21 as the RESET pin.");
NRF_UICR-> PSELRESET[0]=21;  //designate pin pO.21 as the RESET pin
NRF_UICR-> PSELRESET[1]=21;  //designate pin pO.21 as the RESET pin

Serial.println();
Serial.println("Confirming that RESET pin assigment took hold:");
Serial.print(counter);
Serial.print(", PSELRESET[0]=");
Serial.println(NRF_UICR-> PSELRESET[0]);
Serial.print(counter++);
Serial.print(", PSELRESET[1]=");
Serial.println(NRF_UICR-> PSELRESET[1]);

Serial.println();
Serial.println("Return CONFIG to read-only mode.");
NRF_NVMC->CONFIG=0;  // Put the UICR back into read-only mode.

Running it once seems to be good enough, unless there were to occur another "Erase All" or "Burn bootloader" event.

Here is the output from running the code which shows that it succeeded:

Testing...
0, PSELRESET[0]=4294967295
0, PSELRESET[1]=4294967295

Write-enabling CONFIG.

Now designating pin pO.21 as the RESET pin.

Confirming that RESET pin assigment took hold:
1, PSELRESET[0]=21
1, PSELRESET[1]=21

Return CONFIG to read-only mode.

[NeverDie]

Until a more elegant solution can be found, I'm using this in the setup() routine as the workaround:

  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.
  }

The code has the positive virtue of not writing to the RESET rregisters unless both registers are erased. That helps ensure that the non-volatile memory does not get worn out prematurely.

[NeverDie]

@NeverDie said in nRF5 Bluetooth action!:

Until a more elegant solution can be found, I'm using this in the setup() routine as the workaround:

  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.
  }

The code has the positive virtue of not writing to the RESET rregisters unless both registers are erased. That helps ensure that the non-volatile memory does not get worn out prematurely.

Good news! I've confirmed that doing this does indeed solve the problem I previously had with the EByte nRF52832 module not reacting to a reset on pin P0.21. After inserting the above code block into the nRF52832's setup() routine, I can now, using ESP-LINK, remotely reset an nRF52832 module:
https://www.openhardware.io/view/443/nRF52832-ESP-LINK-Shield-for-ESP8266-Wemos-D1-Mini

[NeverDie]

With that issue now settled, I'm moving on to a different topic: what happens if you put the radio into Tx mode, but with an empty buffer (i.e. nothing to send)? In this scenario an RFM69 transmits a continuous pre-amble, and I'm wondering whether the nRF52832 does the same?
With an empty buffer, does it transmit anything at all? Anyone happen to know?

The reason I ask is that I want to program the radio to send a continuous signal so as to quickly wake-up a receiver. With packets, there's the lag time of receiving and decoding the packet, rather than just reacting to a high RSSI. In this way, I can use much narrower listen windows and thereby save a lot of current consumption.

[NeverDie]

According to the datasheet, the typical RSSI sample period is just 0.25us. However, what spoils that a bit is that the radio has to come up to speed beforehand.

Anyhow, on the receive side, I now have at least that much working.

[NeverDie]

It looks as though the start-up time for the radio is about 390us. So, it does save a lot of current to first check the RSSI level rather than to always listen for a packet.

[NeverDie]

When I measure RSSI on the nRF52832, I get what seems like a rather odd range of values: between about 94 and 127. If I have no other nodes transmitting, then the RSSI is generally around 100. If I set up another node which deliberately transmits on the same channel, then the RSSI is pegged at 127.

Is that what others here are also seeing? Here's the test code:

uint8_t theRSSI;
void loop() {
  
NRF_RADIO->TASKS_RXEN=1;  //start revving up the receiver
while (!(NRF_RADIO->EVENTS_READY)) {} //busy-wait until radio ready to receive
NRF_RADIO->TASKS_RSSISTART=1;  //Take exactly one RSSI sample
while (!(NRF_RADIO->EVENTS_RSSIEND)) {}  //Busy-wait until RSSI sample is completed.
theRSSI = NRF_RADIO->RSSISAMPLE;

Serial.println(theRSSI);
Serial.flush();
sleep(1000);
}

[NeverDie]

Unfortunately, when I use the above code block and test the current using an oscilliscope, it becomes clear that the radio never actually goes to sleep:

So, to do that, I add the line:

NRF_RADIO->TASKS_DISABLE=1;  //turn-off the radio

just prior to sleep(100). Doing that largely eliminates the current drain while sleeping:

However, if I do that, then the RSSI that gets reported is always 127. Why? Do I need some other way to check the radio states? Maybe STATE from section 23.14.25 STATE of the datasheet would work better?

[NeverDie]

Found a breakout board for the nRF51822-04: https://oshpark.com/shared_projects/zqDQaykJ

[NeverDie]

The datasheet is possibly a bit misleading when it says:

For the RSSI sample to be valid the radio has to be enabled in receive mode (RXEN task) and the reception
has to be started (READY event followed by START task).

I'm finding that the radio needs to be in either RXIDLE state or RX state to get a plausible RSSI measurement. I can't get a reasonable RSSI measurement while within the RXRU state.

[d00616]

@NeverDie said in nRF5 Bluetooth action!:

The datasheet is possibly a bit misleading when it says:

For the RSSI sample to be valid the radio has to be enabled in receive mode (RXEN task) and the reception
has to be started (READY event followed by START task).

I'm finding that the radio needs to be in either RXIDLE state or RX state to get a plausible RSSI measurement. I can't get a reasonable RSSI measurement while within the RXEN state.

In the ESB code, I use the bitcounter event to start the rssi sample task via PPI. The results are looking plausible.

[NeverDie]

I've found that I get a slightly stronger RSSI signal by about 3dB if I measure it while in the RX state rather than the RXIDLE state.

[NeverDie]

@d00616 said in nRF5 Bluetooth action!:

In the ESB code, I use the bitcounter event to start the rssi sample task via PPI. The results are looking plausible.

Do you know of any good PPI tutorials? The datasheet seems awfully skimpy on its explanation of exactly how to use it.

Right now I have RSSI triggers working on the receiver (presently using the MCU, not PPI), but it takes 1400 samples to guarantee not missing any transmissions. That's because of the gap between single shot packets when they get sent. If I can reduce that to one sample, by finding a way to make a transmitter transmit continuously, then that will save a lot of energy on the receiver.

There is a way to do more rapid fire transmission of packets, so that would be the fall-back plan if I can't find a way to, for example, send a continuous preamble.

[NeverDie]

Answering my own question: it turns out that if you enter into TX mode without any payload, it just sends a null packet and returns to TXIDLE. So, it is not like the RFM69, which would simply send an indefinitely long preamble until there's a payload to send.

The goal is to close the gap between packets as much as possible. So, I'm getting some improvement by just immediately switching back into TX mode (to send another null packet) the moment I've confirmed that TXIDLE state has re-occured.

[NeverDie]

As it turns out, using the above method packs the null packets so tightly that I can rely on a single RSSI measurement (instead of 1400 of them) to guarantee that a transmission won't be missed. So, the goal is achieved.

It sounds as though combining PPI with this would drive the energy consumption even lower!

[d00616]

@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.

@NeverDie said in nRF5 Bluetooth action!:

Do you know of any good PPI tutorials? The datasheet seems awfully skimpy on its explanation of exactly how to use it.

To understand PPI you have to be in mind that nearly everything is driven by tasks and events. If you want to do something, you have to start a task like 'NRF_RADIO->TASKS_TXEN=1'. If a task ends it generates an event like 'NRF_RADIO->EVENTS_READY'. You can replace NRF_RADIO with another periphery the registers have an equal naming scheme.

For an event an Interrupt can be enabled with the NRF_RADIO->INTENSET register. Each event correspondents with a bit in that register. In an interrupt, you have to reset the NRF_RADIO->EVENTS_READY register to 0 to allow triggering a new interrupt. For compatibility, you can use the NRF_RESET_EVENT macro in interrupts. This reads back the register on nRF52 to avoid caching effects. Interrupts doesn't matter for PPI

The next fine thing are Shortcuts. Shortcuts are limited to the same peripheral unit. Bits in the NRF_RADIO->SHORTS register are corresponding to a connection between an event and a test. If the event is triggered the task is started. This allows to trigger things like send an packet after the radio is ready. To use this, you have to enable the shortcut in the NRF_RADIO->SHORTS register.

To break the limits of shortcuts, there is the PPI unit with 32 channels. Some of the channels are predefined but interesting to see how things are implemented with BLE. The other PPI channels are flexible. To use one of these channels, you have to write a pointer of your event register, like '(uint32_t)&NRF_RADIO->EVENTS_END' to the NRF_PPI->CH[YOUR_CHANNEL].EEP register and a pointer to your task you want to start in the NRF_PPI->CH[YOUR_CHANNEL].TEP register like '(uint32_t)&NRF_TIMER0->TASKS_START'. Then you have to enable the PPI channel by setting the corresponding bit like 'NRF_PPI->CHENSET |= (1 << COUR_CHANNEL)' that's all.

The nRF52, but not the nRF52 comes with NRF_PPI->FORK[YOUR_CHANNEL].TEP registers. in my reading you can start a second task with this register like writing to NRF_PPI->CH[YOUR_CHANNEL].TEP.

I have no idea about using the PPI Groups.

Arudino provides a PPI library for the primo: http://cdn.devarduino.org/learning/reference/ppi I think we have to use this library to be compatible in the future. I hope there is a chance to port things to arduino-nrf5 back.

Edit: The arduino PPI library is not flexible enough to support radio events.

[NeverDie]

Thanks! At least notionally, the PPI sounds excellent. Presently, if I want to move the radio into a particular state which takes a few state changes to get there, using the MCU with a conservative coding style, I have to initiate the first state change, then busy-wait until the new state is confirmed, then make the next state-change, etc. It sounds as though the PPI is a good fit for this, because it would eliminate the busy-waits. It would automatically transition from one state to the next using just the interrupt scheme you outlined until the target state is reached. Well, at least in theory. Meanwhile the CPU could be doing other things or sleeping. This does sound like a definite improvement, especially for more efficient control over the radio.

[NeverDie]

@d00616 said in nRF5 Bluetooth action!:

@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)
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

[NeverDie]

However, it does raise the question: if I were to use EVENTS_TICK to trigger some PPI actions, how could PPI also be used to set EVENTS_TICK back to zero so that those actions can be repeated on the next TICK? I haven't yet found an PPI TASKS that can directly manipulate, or even just clear, a particular memory location.

[NeverDie]

Since there are no apparent shortcuts pertaining to the RTC, it looks as though all non-MCU manipulations will have to happen via PPI.

I don't see how to clear a TICK using PPI, so I think the simplest thing would be clearing the counter back to zero if it hits one.

If there's no way to do this basic thing, then I see no way to have a "listen mode" equivalent for the nRF52832 that runs via PPI.

So, adapting what @d00616 wrote earlier, maybe the PPI code to do that would be:

  #define CHANNEL (1)
  NRF_PPI->CH[CHANNEL].EEP = (uint32_t)&NRF_RTC0->COUNTER;  //when COUNTER goes from zero to one.
  NRF_PPI->CH[CHANNEL].TEP = (uint32_t)&NRF_RTC0->TASKS_CLEAR;  //clear COUNTER back to zero.
  NRF_PPI->CHENSET = (1 << CHANNEL) ;

Well, it does compile, but it doesn't work. I think it doesn't work because COUNTER is not an event.

Unfortunately, changing COUNTER to EVENTS_TICK fails also:

  NRF_PPI->CH[0].EEP = (uint32_t)&NRF_RTC0->EVENTS_TICK;  //when TICK occurs.
  NRF_PPI->CH[0].TEP = (uint32_t)&NRF_RTC0->TASKS_CLEAR;  //clear COUNTER back to zero.
  NRF_PPI->CHENSET=1;   //Enable Channel 0.

Unfortunately, the PPI Example code from Nordic's SDK doesn't look even remotely similar to what we're doing here.

Anyhow, the last thing I tried was this:

  NRF_RTC0->INTENSET=1;  //Allows TICK to create an interrupt.
  NRF_PPI->CH[0].EEP = (uint32_t)&NRF_RTC0->EVENTS_TICK;  //when TICK occurs.
  NRF_PPI->CH[0].TEP = (uint32_t)&NRF_RTC0->TASKS_CLEAR;  //clear COUNTER back to zero.
  NRF_PPI->CHENSET=1; //enable Channel 0.

hoping that it might make a difference, but it still fails. Why? What is wrong with it?

[Uhrheber]

@NeverDie said in nRF5 Bluetooth action!:

EVENTS_TICK

From the datasheet:

15.6 Events
Events are used to notify peripherals and the CPU about events that have happened, for example, a state
change in a peripheral. A peripheral may generate multiple events with each event having a separate
register in that peripheral’s event register group.
An event is generated when the peripheral itself toggles the corresponding event signal, and the event
register is updated to reflect that the event has been generated. See Figure 10: Tasks, events, shortcuts,
and interrupts on page 68. An event register is only cleared when firmware writes a '0' to it.
Events can be generated by the peripheral even when the event register is set to '1'.

Maybe I don't get the problem here, but the way I see it, you have to actively write a '0' to the event register to clear it, but in fact it shouldn't matter, because the timer can nevertheless generate an event.

[NeverDie]

@Uhrheber said in nRF5 Bluetooth action!:

you have to actively write a '0' to the event register to clear it

This is right. I later confirmed it (see above), but thank you for the passage in the datasheet. I could have sworn that somewhere the DS said that events were read-only, but the passage you quoted contradicts that recollection. So, thank you again.

Any thoughts on the PPI question (directly above your post)?

[Uhrheber]

So, you want to shut the CPU down, leaving only RTC and PPI running, and generate a wakeup event every 100ms, did I get that right?
I didn't dig that far into the datasheet, and also I don't have any board for testing (yet).

Also, I didn't check whether the debugger will survive a power down/up cycle.
Does it?

[NeverDie]

@Uhrheber said in nRF5 Bluetooth action!:

So, you want to shut the CPU down, leaving only RTC and PPI running, and generate a wakeup event every 100ms, did I get that right?

Yes. I hope to do more than only just that using the PPI while the CPU sleeps, but that does seem like the first step.

[NeverDie]

@Uhrheber said in nRF5 Bluetooth action!:

Also, I didn't check whether the debugger will survive a power down/up cycle.
Does it?

Don't know. I haven't started using the debugger yet.

[Uhrheber]

In this example from Nordic, they're using the RTC's compare interrupt:
http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.nrf52%2Fdita%2Fnrf52%2Fapp_example%2Fsolar_beacon%2Fintroduction.html

Average current consumption is 19µA, including sensor reading, data transmission and Bluetooth advertizing.
Not too bad, I'd say.

[NeverDie]

@Uhrheber said in nRF5 Bluetooth action!:

In this example from Nordic, they're using the RTC's compare interrupt:

Yeah, but that part of it is running on the MCU, not the PPI.

void RTC0_IRQHandler(void)
{
    NRF_RTC0->EVTENCLR = (RTC_EVTENCLR_COMPARE0_Enabled << RTC_EVTENCLR_COMPARE0_Pos);
    NRF_RTC0->INTENCLR = (RTC_INTENCLR_COMPARE0_Enabled << RTC_INTENCLR_COMPARE0_Pos);
    NRF_RTC0->EVENTS_COMPARE[0] = 0;
    
    m_rtc_isr_called = true;    
}

[NeverDie]

Anyhow, I don't see a way to do an RFM69 style "listen mode" using just the PPI on the nRF52832. I think this may be a dead end.

[NeverDie]

Looks as though there is EVTEN, which on the RTC needs to be enabled to get the PPI to work. Shown in Figure 46.

[NeverDie]

Bingo! Added this, and it now works:

  NRF_RTC0->EVTENSET=1;  //enable routing of RTC events to PPI.

[NeverDie]

More good news. As far as the PPI is concerned, an event such as OVRFLW is still just as active as if it had been cleared, even if it hasn't. Here's the proof:

  NRF_RTC0->TASKS_TRIGOVRFLW=1;

  NRF_PPI->CH[0].EEP = (uint32_t)&NRF_RTC0->EVENTS_OVRFLW;  //when RTC overflow occurs.
  NRF_PPI->CH[0].TEP = (uint32_t)&NRF_RTC0->TASKS_TRIGOVRFLW;  //set COUNTER to be near another overflow.
  NRF_PPI->CHENSET=1; //enable Channel 0.
  NRF_RTC0->EVTENSET=B10;  //enable routing of RTC OVRFLW events to PPI.

functions as follows:
https://pastebin.com/Z09e7tMK

[d00616]

@NeverDie said in nRF5 Bluetooth action!:

Anyhow, I don't see a way to do an RFM69 style "listen mode" using just the PPI on the nRF52832. I think this may be a dead end.

It looks like you are implementing a new radio protocol and you are coming forward.

What do you think about forking the MY_RADIO_NRF5_ESB into a new one? The nRF5 code is designed to implement additional protocols for nRF5.

If you remove the address reverse code, there are no OTA conflicts with the ESB protocol. The address width can be enhanced by 2 bits to allow better AES encryption and lager packages.

[NeverDie]

@d00616 said in nRF5 Bluetooth action!:

It looks like you are implementing a new radio protocol and you are coming forward.

Yes, I'm presently focused on trying to reduce the amount of energy consumed by probably the hardest case of all: a battery/solar/supercap receiver that needs to be both highly responsive (within 100ms) and listening 24/7 without running out of juice. Of course, one can always throw bigger batteries or bigger solar panels at the problem, but I'm first trying to be as ultra efficient as possible so that won't be necessary. The benefit will be smaller size, not to mention lower cost.

I am posting my findings as I go because there is precious little in the way of working examples, so I may yet still be of help to others in that way. From the view count, it does seem that people are reading this thread, even if not many are posting.

[d00616]

@NeverDie said in nRF5 Bluetooth action!:

I am posting my findings as I go because there is precious little in the way of working examples, so I may yet still be of help to others in that way. From the view count, it does seem that people are reading this thread, even if not many are posting.

btw. Thank you for sharing you knowledge here. In my option this is very helpful for me.

[NeverDie]

@d00616

I think you'll find this interesting:

  NRF_RADIO->TASKS_DISABLE=1;  //sleep the radio
  while (NRF_RADIO->STATE) {}; //wait until radio is DISABLED (i.e. STATE=0);

  NRF_RTC0->TASKS_TRIGOVRFLW=1;  //set COUNTER to trigger an overflow after 16 TICKS.

  NRF_PPI->CH[0].EEP = (uint32_t)&NRF_RTC0->EVENTS_OVRFLW;  //when RTC overflow occurs.
  NRF_PPI->CH[0].TEP = (uint32_t)&NRF_RTC0->TASKS_TRIGOVRFLW;  //set COUNTER to be near another overflow.
  NRF_PPI->FORK[0].TEP = (uint32_t)&NRF_RADIO->TASKS_RXEN;  //turn on the radio receiver
  NRF_RTC0->EVTENSET=B10;  //enable routing of RTC OVRFLW events to PPI.

  //When Radio state TXIDLE is reached, perform an RSSI sample.  There is no shortcut for this, so we must use PPI.
  NRF_PPI->CH[1].EEP = (uint32_t)&NRF_RADIO->EVENTS_READY;  //After event READY, radio shall be in state TXIDLE.
  NRF_PPI->CH[1].TEP = (uint32_t)&NRF_RADIO->TASKS_RSSISTART; //Take the RSSI sample

  NRF_PPI->CH[2].EEP = (uint32_t)&NRF_RADIO->EVENTS_RSSIEND;  //After event RSSIEND, RSSI measurement is finished and radio will be in state TXIDLE.
  NRF_PPI->CH[2].TEP = (uint32_t)&NRF_RADIO->TASKS_DISABLE; //Sleep the radio
  NRF_PPI->CHENSET=B111; //enable Channel 2, Channel 1 and Channel 0.
  sleep(1000000000);  //sleep a million seconds so as not to interfere with current measurements.

It sleeps the MCU, and using just PPI, it wakes up the radio every 16 TICKS (each tick is 100ms) and measures the RSSI. Then it puts the radio back to sleep.

So, looking at the current consumption from a macro viewpoint, it's this:

The taller peaks are when the RSSI measurements happen. Zooming in on one of the RSSI measurements, the current consumption is this:

As you can see, very little, and only for a very short time!

[NeverDie]

So all I need now is a way for the PPI to compare the RSSI measurement it obtained above with a threshold benchmark to decide whether or not to wake the MCU, which can take it from there. From that point onward, the regular ESB code could be used.

[NeverDie]

Nordic could have taken this a lot farther if they had included some comparison tasks, so that the PPI could make decisions about what to do next. However, I don't see that there are any that can be used for comparing an RSSI measurement against a benchmark. Too bad.

[Uhrheber]

Great that it works.

But I'm not so convinced about the usefulness of this method, anyways.
I know that a lot of receivers use simple RSSI measurement to implement a low power listening mode, but when you are in a noisy environment, the system will wake up quite often, draining the battery fast. And unless you live in a very remote area, 2.4 GHz IS a noisy environment.

[NeverDie]

@Uhrheber said in nRF5 Bluetooth action!:

Great that it works.

But I'm not so convinced about the usefulness of this method, anyways.
I know that a lot of receivers use simple RSSI measurement to implement a low power listening mode, but when you are in a noisy environment, the system will wake up quite often, draining the battery fast. And unless you live in a very remote area, 2.4 GHz IS a noisy environment.

And your better alternative is....?

[scalz]

@NeverDie said in nRF5 Bluetooth action!:

From the view count, it does seem that people are reading this thread, even if not many are posting.

I'm following your work with interest of course On my side i'm pretty busy on other stuff (rpi and my HA) so i'm missing time for try..I'll be back soon on this!

@NeverDie said in nRF5 Bluetooth action!:

t what to do next. However, I don't see

I thought too, about implementing this kind of listenmode for rfm69 in my HA. What i don't like so much, is I think i would need a dedicated node for the scheduling and it complicates a bit thing. I'm not fond of using gw resources for the wakeup broadcast.
I think, maybe I'm wrong, that, ideally, the best would be "time slots" so everything would be in sync, no flooding broadcast, lost msg, collisions etc.. but that implies some work regarding the lib, and some hw issues (with simple 8bits without precise rtc).

Keep the good work!

[Uhrheber]

@NeverDie None, unfortunately. The manufacturer would have to take care of that, by implementing a low power mode in the receiver (maybe with reduced sensitivity), and an additional low power wakeup pattern detector.
There are transceiver that can do that, but the nRF52 can't.

Some of the simple 433MHz OOK receivers have a low current consumption, but they're pretty insensitive, high bandwidth and low speed, so of not much use except switching some battery powered lamp, or such.

Some time ago I searched for a transceiver with low current receive mode, to use it in a battery powered node, that could be woken up by rf, but found nothing.
All of the standard data transceivers are pretty power hungry.

[Toyman]

Interesting study regarding nrf51/nrf52 power consumption:

https://www.google.ru/url?sa=t&rct=j&q=&esrc=s&source=web&cd=5&ved=0ahUKEwiYupPV06TWAhWBJZoKHR-jCO8QFgg-MAQ&url=http%3A%2F%2Fjournal-dl.com%2Fdownloadpdf%2F5910880e3fbb6e13743d5780&usg=AFQjCNGv9O3fK4NXNSxd7MD3Rkkm2Qu7bQ

[Uhrheber]

@Toyman Indeed:

Nonetheless, larger AA or AAA type
batteries are still required to reliably achieve operation times
of a year or longer with high advertising rates.

As I thought.
And for more advanced modulations, like LoRa, the power consumption is even higher.

[NeverDie]

@Uhrheber said in nRF5 Bluetooth action!:

Some time ago I searched for a transceiver with low current receive mode, to use it in a battery powered node, that could be woken up by rf, but found nothing.

TI and Silicon Labs have both had chips with "wake on radio". e.g. http://www.ti.com/lit/an/swra126b/swra126b.pdf

The Rx current consumption of the nRF52832 seems pretty good, especially with DCDC regulator enabled. Seems to me that the RSSI detection implemented in PPI is a big improvement, even in noisy environments for the following reasons: the RSSI measurement takes only 0.25us, according to the DS. That's very little overhead. If the Radio gets switched on due to a false positive on the RSSI, well, it would have had to be switched on anyway even without the RSSI. I don't see the downside to this. The more noisy the environment, the less effective the technique is, but I don't see that you'd ever really be worse off for using it.

[NeverDie]

@d00616
If I'm using

sleep(1000000000);

to sleep the CPU while keeping the PPI active, is there a way for the PPI to subsequently wake the CPU so that the CPU can resume where it left off? I'm not seeing any TASKS which look suitable for doing that. Or do I need an altogether different configuration for sleeping the CPU?

Back on August 5, @RMTUCKER had suggested using:

sleep(digitalPinToInterrupt(10), FALLING,0);

If I were to go that route, I could probably have the PPI toggle PIN 10 to do a wake-up, but I found that, for whatever reason, that method of sleeping had a much higher current draw.

[Edit: scratch that. I just tried "sleep(digitalPinToInterrupt(10), FALLING,0);", and it appears to turn-off PPI. Oddly enough, it appears to leave the RTC running, which is actually just fine by me. However, I need the PPI running too. ]

[Toyman]

@Uhrheber not really. If you read carefully, they claim almost 1year battery life with 1hz (once per sec) advertising.
Typical MYS node sends data once per minute? So, actually, 2-3 years are easily achievable.

[NeverDie]

It turns out the cost in current consumption of waking the MCU merely to check the RSSISAMPLE result is relatively high:

The first hump is the current drawn by the PPI and RSSI sample. The second hump is the current drawn by MCU.

Measurement Scale: 1mv=1ma.

Anyhow, the RSSISAMPLE measurement, as reported by the MCU, is abnormally high. It may be that I need to put the radio into RX state, instead of just RXIDLE, before taking the RSSI measurement.

[NeverDie]

This post is deleted!

[NeverDie]

@d00616

Are there special reserved names to always use for the IRQ handlers? e.g. RADIO_IRQHandler(void), and so on?

[d00616]

@NeverDie said in nRF5 Bluetooth action!:

to sleep the CPU while keeping the PPI active, is there a way for the PPI to subsequently wake the CPU so that the CPU can resume where it left off? I'm not seeing any TASKS which look suitable for doing that. Or do I need an altogether different configuration for sleeping the CPU?

The PPI cannot wake up the CPU. You can try to trigger events to a timer which resumes the CPU.

@NeverDie said in nRF5 Bluetooth action!:

Are there special reserved names to always use for the IRQ handlers? e.g. GPIOTE_IRQHandler(void), and so on?

The names are defined there:

https://github.com/sandeepmistry/arduino-nRF5/blob/dc53980c8bac27898fca90d8ecb268e11111edc1/cores/nRF5/SDK/components/device/nrf52.h#L65

[NeverDie]

@d00616 said in nRF5 Bluetooth action!:

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.

Does the current development software support the use of at most one ISR in total at any one time?

[NeverDie]

@d00616

I changed your example to use sleep(...) instead of delay(...) in the main loop, but what then becomes obvious is that the interrupts don't wake up the MCU. Well, in a sense they do, because the ISR is executed, but the MCU doesn't remain awake like it would on an Arduino. So, how does one escape the sleep mode after it has begun without waiting for it to simply time out?

// This code is public domain

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

//#define RTC NRF_RTC0
//#define RTC_IRQ RTC0_IRQn

int interrupt = 0;

void setup() {
  // put your setup code here, to run once:
  Serial.begin(250000);
  Serial.println("Start");

  // Configure RTC
  NRF_RTC0->TASKS_STOP = 1;
  NRF_RTC0->PRESCALER = 31; //1024Hz frequency
  NRF_RTC0->CC[0] = NRF_RTC0->COUNTER + (3 * 1024);
  NRF_RTC0->EVTENSET = RTC_EVTENSET_COMPARE0_Msk;
  NRF_RTC0->INTENSET = RTC_INTENSET_COMPARE0_Msk;
  NRF_RTC0->TASKS_START = 1;
  NRF_RTC0->EVENTS_COMPARE[0] = 0;

  // Enable interrupt
  NVIC_SetPriority(RTC0_IRQn, 15);
  NVIC_ClearPendingIRQ(RTC0_IRQn);
  NVIC_EnableIRQ(RTC0_IRQn);
  Serial.println();
  Serial.println();
  Serial.println("Starting...");
}

void loop() {
  Serial.print(millis());
  Serial.print(" ");
  Serial.print(NRF_RTC0->COUNTER);
  Serial.print(" ");
  Serial.println(interrupt);
  sleep(10000);
}

/**
 * Reset events and read back on nRF52
 * http://infocenter.nordicsemi.com/pdf/nRF52_Series_Migration_v1.0.pdf
 */
#if __CORTEX_M == 0x04
#define NRF5_RESET_EVENT(event)                                                 \
        event = 0;                                                                   \
        (void)event
#else
#define NRF5_RESET_EVENT(event) event = 0
#endif

// This must be in one line
extern "C" { void RTC0_IRQHandler(void) { NRF5_RESET_EVENT(NRF_RTC0->EVENTS_COMPARE[0]); interrupt++; NRF_RTC0->TASKS_CLEAR = 1; }}

I guess maybe the answer is to clear the SLEEPONEXIT bit in the System Control Register (SCR) before exiting the ISR? The SCR is described on page 4-19 of: http://infocenter.arm.com/help/topic/com.arm.doc.dui0553a/DUI0553A_cortex_m4_dgug.pdf
At the moment, though, I'm not even sure how to access that register, as so far I've only seen the API for the nRF52832 generally, not the code interface for the ARM Cortex M4 per se that's inside it.

[rmtucker]

@NeverDie
I am a little lost with this,I am using sleep and wake from ext int on the nrf51 and it has been working every second for the last 2 weeks.
What kind of int are you trying to implement?

[NeverDie]

@rmtucker said in nRF5 Bluetooth action!:

@NeverDie
I am a little lost with this,I am using sleep and wake from ext int on the nrf51 and it has been working every second for the last 2 weeks.
What kind of int are you trying to implement?

This is for the case where the PPI is doing things (like, for example, getting the radio to periodically listen for incoming packets) all while the CPU is sleeping. If, for instance, a packet is received in that mode, the CPU needs to be awoken to process it.

So, this is different than the easier case (which I already have working) of sleeping the CPU, then it wakes up every, say, 100ms, and then the CPU controls the radio to listen for packets and then takes action if one is received. Instead, this is a case where the PPI is controlling the radio while the CPU sleeps.

The PPI has a lot of power saving potential, so we're figuring out how best to exploit that potential.

Also, the more general topic of how to use interrupts and ISR's on the nRF52832 (such as how many different ones can be active at once, as supported by the current development code) needs to be addressed, independent of the regular sleep(..) function.

[rmtucker]

This post is deleted!

[NeverDie]

@rmtucker said in nRF5 Bluetooth action!:

@NeverDie
All we need right now is a controller that covers the majority of home use.
Tried domoticz for 2 years and it covers energy use and cost really well but then is limited to saving data every 5mins and no mixed/multisensor graphs to any extent so useless for my current needs.
Tried myHouse for 6 months and it,s graphing was great but the display of binary sensors were not in real time and it does not do energy use at all.
I can not find a controller that seems to cover average needs for automation/energy/and realtime feedback.
I know it's a little off topic but it is a big problem when you can build the range of mysensors using the nrf5 but then not be able to get the feedback and energy/cost stuff on the screen.
Maybe i am just disgruntled that the controllers do not seem to keep up with the electronics very well.

Yes, agreed, but please let's not go into that here, because it would seriously throw us off topic. You might try: https://forum.mysensors.org/topic/7178/are-folks-here-happy-with-domoticz/63 which has some useful suggestions, especially regarding Node Red and MQTT.

[rmtucker]

@NeverDie
Sorry mate i have deleted it i am just a little miffed with the controller searching

[NeverDie]

@NeverDie said in nRF5 Bluetooth action!:

At the moment, though, I'm not even sure how to access that register, as so far I've only seen the API for the nRF52832 generally, not the code interface for the ARM Cortex M4 per se that's inside it.

OK, the file core_cm4.h is where the structure that contains the SCR is defined:

typedef struct
{
  __IM  uint32_t CPUID;                  /*!< Offset: 0x000 (R/ )  CPUID Base Register */
  __IOM uint32_t ICSR;                   /*!< Offset: 0x004 (R/W)  Interrupt Control and State Register */
  __IOM uint32_t VTOR;                   /*!< Offset: 0x008 (R/W)  Vector Table Offset Register */
  __IOM uint32_t AIRCR;                  /*!< Offset: 0x00C (R/W)  Application Interrupt and Reset Control Register */
  __IOM uint32_t SCR;                    /*!< Offset: 0x010 (R/W)  System Control Register */
  __IOM uint32_t CCR;                    /*!< Offset: 0x014 (R/W)  Configuration Control Register */
  __IOM uint8_t  SHP[12U];               /*!< Offset: 0x018 (R/W)  System Handlers Priority Registers (4-7, 8-11, 12-15) */
  __IOM uint32_t SHCSR;                  /*!< Offset: 0x024 (R/W)  System Handler Control and State Register */
  __IOM uint32_t CFSR;                   /*!< Offset: 0x028 (R/W)  Configurable Fault Status Register */
  __IOM uint32_t HFSR;                   /*!< Offset: 0x02C (R/W)  HardFault Status Register */
  __IOM uint32_t DFSR;                   /*!< Offset: 0x030 (R/W)  Debug Fault Status Register */
  __IOM uint32_t MMFAR;                  /*!< Offset: 0x034 (R/W)  MemManage Fault Address Register */
  __IOM uint32_t BFAR;                   /*!< Offset: 0x038 (R/W)  BusFault Address Register */
  __IOM uint32_t AFSR;                   /*!< Offset: 0x03C (R/W)  Auxiliary Fault Status Register */
  __IM  uint32_t PFR[2U];                /*!< Offset: 0x040 (R/ )  Processor Feature Register */
  __IM  uint32_t DFR;                    /*!< Offset: 0x048 (R/ )  Debug Feature Register */
  __IM  uint32_t ADR;                    /*!< Offset: 0x04C (R/ )  Auxiliary Feature Register */
  __IM  uint32_t MMFR[4U];               /*!< Offset: 0x050 (R/ )  Memory Model Feature Register */
  __IM  uint32_t ISAR[5U];               /*!< Offset: 0x060 (R/ )  Instruction Set Attributes Register */
        uint32_t RESERVED0[5U];
  __IOM uint32_t CPACR;                  /*!< Offset: 0x088 (R/W)  Coprocessor Access Control Register */
} SCB_Type;

Unfortunately, I just checked its status, and it's already cleared. So, something else is causing the MCU to go back to sleep at the end of the ISR.

The problem is that an ISR needs to be as short as possible. If something more elaborate needs to happen as a result of an interrupt, whether it be printing a bunch of debug information or something else, it should happen outside the ISR. Right now I don't see how to do that, because the MCU always immediately goes back to sleep after the ISR finishes. I suppose it must be something inside the sleep(..) routine that causes this?

[NeverDie]

I suspect it may be the while statement in this part of the library code that's doing it:

int8_t hwSleep(unsigned long ms)
{
	hwSleepPrepare(ms);
	while (nrf5_rtc_event_triggered == false) {
		hwSleep();
	}
	hwSleepEnd(ms);
	return MY_WAKE_UP_BY_TIMER;
}

[NeverDie]

Yup, that was it. I excised the while-loop and re-wrote it as a differently named function, which I now call instead of sleep(..):

int8_t myHwSleep(unsigned long ms)
{
  hwSleepPrepare(ms);
  //while (nrf5_rtc_event_triggered == false) {
    hwSleep();
  //}
  hwSleepEnd(ms);
  return MY_WAKE_UP_BY_TIMER;
}

and it now works "correctly"--well, at least what I want it to do. I'll flag it for @d00616, who may have good reasons for keeping it as-is.

[Omemanti]

@NeverDie said in nRF5 Bluetooth action!:

From the view count, it does seem that people are reading this thread, even if not many are posting.

I follow your journey with great interest, one day Ill find the time to do something with it

[rmtucker]

Just wondering if ota updates are possible with the nrf5 because it does not have the usual memory constraints?

[NeverDie]

Epilog: It turns out that the reason I was getting erroneous readings of RSSISAMPLE by the CPU is that the radio must be turned-on when that register is being read. I had hoped it was being stored somewhere else in memory, but it's not. So, probably the best that can be done from an energy standpoint is to have the PPI pipeline the waking of the radio and the CPU from sleep, such that neither is waiting for the other to wake up in order to get work done. Ideally, the moment the RSSI measurement is taken by the PPI, the CPU would have just then fully woken up and be able to evaluate RSSISAMPLE, while the radio is still turned on.

A different approach would be to have the PPI cyclically wake the radio into Rx mode for a period of time and then shut it down. If it received a packet, it would trigger a wake-up on the CPU. This is more or less how the RFM69's "listen mode" works. I may give this a try also so as to measure whether total current consumed is greater or less than the current consumed by the revised RSSI approach (above). I think it might. Although the radio has to remain on longer than it would if it were doing purely an RSSI measurement, it has the advantage that the CPU can remain asleep until an actual packet is received. Given that the radio spends a lot of time just ramping up after being disabled, I'm guessing the incremental Rx time needed for packet detection won't seem so much in comparison. The hard part to this approach will be timing just how long the Radio is in RX mode. Although there are technically three RTC instantiations that can be used, they all share the same prescaler.

So, in order to create a short delay timer, I set one GPIO pin high, which charges a second GPIO pin through a very small capacitor and diode in parallel. Then, when the first GPIO pin goes low, the voltage on the second GPIO pin decays. By setting a PPI event on the second pin to trigger from a Hi2Lo transition, I'm able to create an analog delay, which varies in duration depending on the value of the capacitor. Presently, using a 2.2nF capacitor creates about a 2ms delay between the first pin going LOW and the second pin detecting a Hi2Lo event. It is that event which could be used to trigger turning off the radio after it has listened for packets, whereas it is the first pin going LOW that would have triggered turning on the radio and putting it into RX mode. This is all controlled by the PPI, so no energy needs to be used by the CPU.

If anyone can think of a better or more of a digital way to create a predictable time delay, please do post. However, I'm using this method for now just for proof of concept purposes.

[NeverDie]

Here's a scope capture of it:

The yellow line shows the rapid charging and then subsequent decay of voltage on the second pin. The blip on the blue line shows that after slightly more than 2ms, the Hi2Lo event was triggered, because the voltage on the second pin had dropped enough for the Hi2Lo transition to occur. As you can see, it happens at around 1v. I was able to capture it on the scope because I used that event to very briefly set a third pin (the one whose voltage is being tracked by the blue line) HIGH.

Again, all of this is being managed by the PPI while the CPU is asleep.

[d00616]

@NeverDie said in nRF5 Bluetooth action!:
If your goal is to minimize the RX-on time, then you can trigger the RX start and stop by a timer for your minimal window where the frame must be start. Then use the bitcounter top stop the timer in case a packet is received. A shortcut to the end is disabling the RX mode. You can wakeup the CPU with the END event.

P.S.: you can reduce the RX/TX time by enabling fast ramp up in MODECNF0 if you haven't to care about nRF51 compatibility.

[NeverDie]

@d00616 said in nRF5 Bluetooth action!:

@NeverDie said in nRF5 Bluetooth action!:
If your goal is to minimize the RX-on time, then you can trigger the RX start and stop by a timer for your minimal window where the frame must be start. Then use the bitcounter top stop the timer in case a packet is received. A shortcut to the end is disabling the RX mode. You can wakeup the CPU with the END event.

P.S.: you can reduce the RX/TX time by enabling fast ramp up in MODECNF0 if you haven't to care about nRF51 compatibility.

Thanks! It finally dawned on me that having the PPI use the RTC's CC registers would be a far better way to schedule turning on and off the radio's RX than using the stopgap analog delay that I had devised (above). Your interrupt handler example helped me see what had been staring me in the face the entire time, but without my recognizing it as the answer to the problem. Funny how that can sometimes happen, where the whole gestalt can just suddenly change. So, thanks again for sharing your example code. This will be a much less awkward solution!

[NeverDie]

Where exactly do I look to find all the pin mappings that are assumed for the "Generic nRF52" board? For example, what are the pin numbers that are assumed for RXI, TXO, MISO, MOSI, etc.?

[rmtucker]

@NeverDie
/variants/Generic/variant.h i think