nRF5 action!

[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

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

:)