ATtiny402 (0 series) observations

Go To Last Post
14 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

 

 

Although Moe123 has been kind enough to suggest that I could write a tutorial/guide for some of the features of the ATtiny 0 series, I don't yet have enough information gathered to produce one, neat topic. I also need to make progress on the current projects before I can gather my thoughts into anything useful as learning material.

 

So I thought I'd start a thread with perhaps notes on what I have found using my ATtiny402 that may not be obvious on first read of the datasheet (which is already ranking low in our trust because there's been such an attempt at common data for common parts that we're not sure what's been copy-pasted and is wrong!). If this is not the right place to record these notes, please mods feel free to move it and tell me. Hopefully one day I'll have the makings of a tutorial from all the snippets here. At the very least, they may be examples of easy pitfalls for novice users of AVRs in general and the tiny 0 and 1 series specifically.

 

TCB0 interrupt effect on other output pins

Datasheet references: 21.3 [TCB0] Functional Description

The first one I wanted to mention that wasn't obvious to me as a new user - I inadvertently (as in "write 1 to anything which might trigger a pulse"!) set the TCB0 interrupt to fire when I configured it to output its waveform pulse on the WO pin (PA6) in Single Shot mode (Figure 21-8 in the 202/402 datasheet). Here's the timer setup.

  TCB0.CCMP = 0x0001; /* Compare or Capture: 0x0 0x7FFF; */
  TCB0.CNT = 0x0001; /* Count: 0x0 */
  TCB0.CTRLB = 0 << TCB_ASYNC_bp /* Asynchronous Enable: disabled */
               | 1 << TCB_CCMPEN_bp /* Pin Output Enable: enabled */
               //     | 0 << TCB_CCMPINIT_bp /* Pin Initial State: disabled */
               | TCB_CNTMODE_SINGLE_gc; /* Single Shot */
  // TCB0.DBGCTRL = 0 << TCB_DBGRUN_bp; /* Debug Run: disabled */
  TCB0.EVCTRL = 1 << TCB_CAPTEI_bp; /* Event Input Enable: enabled */
  //     | 0 << TCB_EDGE_bp /* Event Edge: disabled */
  //     | 0 << TCB_FILTER_bp; /* Input Capture Noise Cancellation Filter: disabled */
  TCB0.INTCTRL = 1 << TCB_CAPT_bp; /* Capture or Timeout: enabled */
  TCB0.CTRLA = TCB_CLKSEL_CLKDIV1_gc /* CLK_PER (No Prescaling) */
               | 1 << TCB_ENABLE_bp; /* Enable: enabled */
  //     | 0 << TCB_RUNSTDBY_bp /* Run Standby: disabled */
  //     | 0 << TCB_SYNCUPD_bp; /* Synchronize Update: disabled */

Bear in mind that I have not set up an ISR to handle this timer interrupt! After initialising some other pins as output, PA7 as an event input and the event system to fire TCB0, based on PA7, I couldn't get any of the other pins to act as digital outputs. I wanted to use one to tell whether the PAn event generator was doing just rising edges or falling edges too. I had to comment out this line to get the other pins to output OUTSET commands:

    //TCB0.INTCTRL = 1 << TCB_CAPT_bp; /* Capture or Timeout: enabled */

I haven't dug into the datasheet but it seems funny to me that the GPIOs are affected by the TCB0 flag being raised but not handled in the ISR, however the TCB0 single shot kept functioning perfectly!

 

Event Generator: I/O Port pins 

Datasheet references:  14.5.3 Asynchronous Channel n Generator Selection ,  14.5.5 Asynchronous User Channel n Input Selection,  16.5.11 Pin n Control

I wanted to generate an event to trigger TCB0 in single shot mode. Because the event is a falling edge, I tried to use a connection to PA7, configured as an input, as an Event Generator. Here's the code which sets PA7 as the event generator for Asynchronous Event Channel 0 and connects TCB0 as an Event User of that Event Channel:

  EVSYS.ASYNCUSER0 = EVSYS_ASYNCUSER0_ASYNCCH0_gc; //enable TCB0 input to take channel 0
  EVSYS.ASYNCCH0 = EVSYS_ASYNCCH0_PORTA_PIN7_gc; //enable event sys to take PA7 logic edge as an input

When I connected up to my oscilloscope, the pulse generated by TCB0 on PA6 is only on a rising edge of PA7's input. I couldn't see anywhere that this was recorded in the event system section of the datasheet, so I thought it worth observing in public. Please open up the discussion here if I have missed something like taking advantage of INVEN in the PORT configuration to make the PA7 Event occur on a falling edge. I may try some of those PORT settings just to explore a bit. EDIT: It absolutely can be configured in the INVEN bit setting for the pin. You can ALSO get single shot events generated on either edge based on the TCB0.EVCTRL register but I had unexpected results with this - read on for more details.

PORTA.PIN7CTRL = PORT_INVEN_bm; // invert the logic of the input (0 = 1 and 1 = 0)

This will now generate the ASYNCCH0 event on a falling edge rather than a rising edge. The datasheet is quite clear now I have looked in the PORT configuration section, especially the helpful PORT block diagram. Here it is with the config used to generate a falling edge event:

Note: I have not set any of the ISC bits in the PINCTRL register - these seem ONLY for interrupts, not events. This makes me think that only RISING and FALLING edges will generate Pin I/O events. Interrupts appear to be able to trigger on RISING, FALLING, BOTH and LOW (but not high - maybe INVEN can sort that for us?!).

 

The next discovery I made was that you can apparently change the event edge which the single shot pulse responds to from within the TCB0 (rather than PORT) settings:

From this I understand that the following set to 1 or 0 will give EITHER a pulse on the rising edge, OR a pulse on the falling edge of the event (PA7 input, in this case). I tried but it appeared to pulse on BOTH the rising AND falling edges of the input pulse. I admit there is some ripple in the blue (PA7 input) trace but to trigger the pulse on both edges seems like unexpected/undocumented behaviour. What do you think? (BTW, PORT INVEN has no effect now both edges generate an event) Here are traces from the same configuration of: 

TCB0.EVCTRL =  1 << TCB_EDGE_bp;

So my experience is that TCB_EDGE = 1 leads to BOTH rising and falling edges being responded to by the single shot pulse. Thoughts? I appreciate that you can't see all the code here and I can post it if that would help.

 

TCB0 Single Shot: Asynchronous versus Synchronous

Datasheet references:  21.3.3.2 [TCB0] Output

There's an option to drive the Waveform Output (WO) to a pin in the new ATtinys. This is similar to functionality of this nature in older microcontrollers. I have never really used it before. In TCB0, on the ATtiny402, WO only goes to one pin - PA6. So if you want this feature, you can't use PA6 for something else at the same time. For example, PA6 is also one of the two fully asynchronous pins on this 5 GPIO (effectively, if you reserve RESET/UPDI) microcontroller. Don't confuse asynchronous pins with asynchronous operation of WO - it's not quite the same. Anyway, when you set up TCB0, you have three key settings that will determine when your pulse starts and finishes (aside from the TCB0.CCMP value, that is). I find the table confusing:

What does  CTRLB = '0' or '1' mean? This is an 8 bit register as far as I can tell:

So I have not attempted to test the difference between two alleged synchronous modes. I have instead tried with CTRLB.ASYNC = 0 and 1.

TCB0.CTRLB = 0 << TCB_ASYNC_bp;
// OR
TCB0.CTRLB = 1 << TCB_ASYNC_bp;

The traces here are for a 5MHz ATtiny402. The blue trace is my GPIO toggling as an input into my event generator (set to generate event on rising edge in this case) and the yellow trace is my Event User, TCB0, operating in single shot mode for a TCB0.CCMP = 0x0001, so only 1 count in there.

 

Here is the trace in synchronous mode, where the pulse starts in time with the clock cycles and finishes in time with the clock cycles:

Note there appears to be an 800ns delay before the pulse begins. It lasts 400ns and ends 1.2us after the rising edge of the event generator pin.

 

Now here's the asynchronous version, where the pulse starts as soon as the event system generates the event and ends when TCB0 has responded to the event, counted up to TCB0.CCMP and ends the pulse in line with clock cycles:

Note that the pulse starts the instant that the event generator pin edge rises but lasts 800ns longer and finishes at exactly the same time as the synchronous version.

 

Perhaps the main takeaway here is that if pulse length control is critical and you want short pulses, go synchronous but if you want to respond as fast as you can to an event and the pulse duration is less critical, go asynchronous. I would be interested if anyone has any ideas about if there is a better interpretation of Table 21-3 than I can make!

 

TCB0: Asynch + Edge = bouncy?

When I tried:

TCB0.EVCTRL = 1 << TCB_EDGE_bp;
TCB0.CTRLB  = 1 << TCB_ASYNC_bp;

I got these traces:

It looks like we're getting an Asynchronous single shot pulse, followed 600ns (3 clock cycles) later by a synchronous (in duration terms) single shot pulse. By the time the second pulse has finished, we're 2.2us from the rising/falling edges that generated the event. The datasheet talks about a noise canceller. I'm not sure it's describing my fairly tidy 0.5Hz square wave but you can make your own mind up: 

So, just to see what it did, I enabled it like this:

TCB0.EVCTRL = 1 << TCB_FILTER_bp;

And these are the traces I got:

Now our pulse is back down to 1.8us, so rather than saying we have just filled in the gap between two pulses, it looks like the claim that the noise canceller adds four clock cycles to the pulse before changing state may be true (although 1200ns + 4 * 200ns = 2000ns, not 1800ns - more deviation from the datasheet or is it just me?!smiley).

 

Finally, to see if my measurement setup was a significant contributory factor, I changed some things. Firstly, the device under test is a bare ATtiny402 sitting on a SOIC8 breakout board, stuffed in a breadboard with a 3.3V supply, GND and UPDI (via resistor) to an Arduino Nano clone in jtag2updi role. The 3.3V rail is the quieter of the two, I understand. I placed a 0.1uF ceramic cap between 402's VCC and GND. No change to the double pulse when I turned the noise filter off. I also changed my oscilloscope probes from 1x to 10x, just in case that helped. No change. Finally, I moved the capacitor between PA1, which was generating the square wave, and GND. Although the size of the cap is comically large for this timescale, I think it nicely shows the trigger thresholds for rising/falling edges on the PA7 input. But still no effect on the unfiltered double async pulse.

Fortunately for me, I don't need to capture both edges (even though that isn't a feature that is apparently available!) and I can avoid setting TCB_EDGE by using PORT_INVEN to select which edge I want to pulse off.  

 

RTC CMP Interrupt doesn't work, at least in Standby?

Datasheet references:  22.3 RTC Functional Description, 22.11.3 Interrupt Control, 

This is not going to be as fleshed out as some of the other observations for now but I can't get seem to get the RTC interrupt to work. I'm using Standby mode, internal 32kHz osc, a range of prescalers, no BOD, 4.7V supply. Bare 402 with an LED and resistor on PA2 to show output. Measurements are being made with a Joulescope (which is awesome BTW) and I can definitely see the 402 entering and leaving sleep. What's confusing me is that I can get the RTC interrupt on OVF and the CMP interrupt is acting like OVF and running until the RTC.PER value, regardless of what I set in RTC.CMP. Writing different values to RTC.PER seems to change the duration between interrupts firing, even with a solely CMP-based interrupt implemented (no OVF involved) and I suppose I could live with this but I wanted to see if someone else can spot what's going on here (datasheet, me, my code)...

Here's key elements of code, for use with megaTinyCore, which uses the Arduino IDE but calls the iotn402.h and hasn't had an issue with register addresses on anything else I have tried:

#include <avr/sleep.h>
#include <avr/interrupt.h>

void RTC_init(void)
{
  while (RTC.STATUS > 0)
  {
    ;                                   /* Wait for all register to be synchronized */
  }
  RTC.CLKSEL = RTC_CLKSEL_INT32K_gc;    /* 32.768kHz Internal Crystal Oscillator (XOSC32K) */
  while (RTC.STATUS > 0)
  {
    ;                                   /* Wait for all register to be synchronized */
  }
  RTC.CTRLA = RTC_PRESCALER_DIV1_gc | RTC_RTCEN_bm | RTC_RUNSTDBY_bm;

 // RTC.INTCTRL |= RTC_OVF_bm;
 RTC.INTCTRL |= RTC_CMP_bm;
 while (RTC.STATUS > 0)
  {
    ;                                   /* Wait for all register to be synchronized */
  }
 RTC.CMP = 0x000F;
 //RTC.PER = 0xFF;
  sei();
}

ISR(RTC_CNT_vect)
{
 // RTC.INTFLAGS = RTC_OVF_bm;
  RTC.INTFLAGS = RTC_CMP_bm;
}

void setup() {
  RTC_init();                           /* Initialize the RTC timer */
  PORTA.DIRCLR = PIN2_bm;
  PORTA.DIRCLR = PIN1_bm;
  PORTA.DIRCLR = PIN0_bm;
  PORTA.DIRCLR = PIN3_bm;
  PORTA.DIRCLR = PIN6_bm;
  PORTA.DIRCLR = PIN7_bm;
  PORTA.PIN1CTRL = PORT_PULLUPEN_bm;
  PORTA.PIN3CTRL = PORT_PULLUPEN_bm;
  //PORTA.PIN6CTRL = PORT_PULLUPEN_bm; // ignore, this is for power saving in full code
  // PORTA.PIN2CTRL = PORT_PULLUPEN_bm; // ignore, this is for power saving in full code
  PORTA.PIN7CTRL = PORT_PULLUPEN_bm;
 // set_sleep_mode(SLEEP_MODE_PWR_DOWN);
    set_sleep_mode(SLEEP_MODE_STANDBY);

  sleep_enable();
}

void loop() {
  PORTA.DIRSET = PIN2_bm;
  PORTA.OUTSET = PIN2_bm;   // LED on
  sleep_cpu();
  PORTA.OUTCLR = PIN2_bm;   // LED off
  PORTA.DIRCLR = PIN2_bm;
  sleep_cpu();
}

 

More observations to come...

 

 

Last Edited: Sat. Jul 20, 2019 - 09:51 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I haven't dug into the datasheet but it seems funny to me that the GPIOs are affected by the TCB0 flag being raised but not handled in the ISR, however the TCB0 single shot kept functioning perfectly!

It depends if you enabled global interrupts. If so, then it starts to turn into a mess, and no amount of logic will help until you step through it. You have a 'not-real' reset (via __bad_interrupt), you get the global interrupt bit cleared in sreg on startup but the lvl0ex bit remains because of there was never a reti, the tcb irq flag still remains set but at this point none of this may no longer matter since the cpu still thinks you are in a level 0 isr. What happens to your other pins along the way, who knows.

 

When I connect up to my oscilloscope, the pulse generated by TCB0 on PA6 is only on a rising edge of PA7's input

datasheet (attiny416)

When the EDGE bit of the TCB.EVCTRL register is written to '1', any edge can trigger the start of counter. 
If the EDGE bit is '0', only positive edges will trigger the start. 

 

You have EDGE set to 0.

 

edit- the original post seems to have grown x10, I was responding to the initial part.

Last Edited: Fri. Jul 19, 2019 - 12:03 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

curtvm wrote:
When the EDGE bit of the TCB.EVCTRL register is written to '1', any edge can trigger the start of counter. 
If the EDGE bit is '0', only positive edges will trigger the start. 

Of course, you are right. But that means unless I have missed something, there's an error in the table at  21.5.3 Event Control (the one I included a snip from above).

 

Thank you for finding that section of text though - completely skimmed past it!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

there's an error in the table at  21.5.3 Event Control

No one is surprised. The tiny416 datasheet tcb edge table matches the text, the 402 does not. 

 

When things don't seem right, I just grab a datasheet from another mcu in the series, it may help or make it worse.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Back in this other thread https://www.avrfreaks.net/commen... kabasan and myself also did some measurements, not with as many configurations as you tried.

Kabasan measured the response of TCB to a synchronous event at 4 cycles, like you. A synchronous even is generated by something that is synchronized with the CPU clock. In your case, a port set by the CPU.

I measured the response to an asynchronous event (for example, if someone pushed a button to trigger the timer) at 3-4 cycles, so a bit faster.

 

The extra test you did was with the TCB_EDGE bit set. That is a somewhat weird behaviour, I don't understand where the second pulse is coming from... maybe a silicon bug that needs to go into the errata.

 

edit: I will replicate your experiment when I have time, over the weekend probably.

edit2: that capacitor on the output is mistreating the chip a bit, isn't it? The current will exceed spec for a few micro-seconds... probably no big deal, I guess. Our test chips have an hard lifedevil

Last Edited: Fri. Jul 19, 2019 - 01:13 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

smerrett79 wrote:
Bear in mind that I have not set up an ISR to handle this timer interrupt!
If you have an sei() for any other reason and this is avr-gcc then _bad_interrupt will come into play:

 

https://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

If you have an sei()

Thanks. I did have sei() but turned it off and the trouble persisted. Turning the interrupt bit off in the timer register is what sorted it. Still think it's funny (not haha!) behaviour but I'm relatively naive about what should and shouldn't happen inside these uCs.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I can't seem to adjust Sleep-standby duration with wake from RTC.CMP interrupt on the 402, despite RTC.PER actually allowing me to achieve the same effect because  RTC.INTCTRL |= RTC_CMP_bm; is behaving like an OVF... Have put more detail in the OP above, please could you gurus comment on why I might be unable to use RTC.CMP and adjust the level (time) at which it returns from standby?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

>I did have sei() but turned it off and the trouble persisted. Turning the interrupt bit off in the timer register is what sorted it.

 

You may have turned it off in an obvious place (the sei), but do you have other code that is turning it on? If you are not generating an asm listing, do it, then search for sei (or search your source files). The timer irq enable bit makes no difference until the global irq's are enabled, so if irq's were off you would see no difference whether the timer irq was enabled or not. 

 

>why I might be unable to use RTC.CMP and adjust the level (time) at which it returns from standby?

 

The rtc timer runs to period, sets the overflow flag, and the counter resets to 0. Along the way if count happens to match compare, then the compare flag is set. I don't really understand the question, but using a compare match only makes sense when you want an irq at some point less than the period, otherwise set period to what you want and use ovf.

 

This simple example will blink an led- the compare match happens at half the period, the compare irq fires, the isr turns on led, then at the overflow the (same) isr turns off the led. Both irq's wake up the cpu from standby.

#include <stdint.h>
#include "Port.hpp"
#include "Slpctrl.hpp"
#include "Rtc.hpp"
#include "Cpuint.hpp"
#include "Port.hpp"

Rtc rtc;
PB5_OUTL_t led1;

int main() {

    Cpuint::set_func( Cpuint::RTC_CNT,
        [](){
            if( rtc.flag( rtc.IRQ_CMP ) ){
                rtc.flagclr( rtc.IRQ_CMP );
                led1.on();
            } else {
                rtc.flagclr( rtc.IRQ_OVF );
                led1.off();
            }
        }
    );
    //default clock is 32kint, period default is 0xFFFF
    rtc.stdbyrun( true ); //required to be a wakeup source from standby
    rtc.irq( rtc.IRQ_CMP, true );
    rtc.irq( rtc.IRQ_OVF, true );
    rtc.compare( 0x7FFF ); //set compare to half of period
    rtc.on( true );

    Cpuint::on( true ); //global irq on

    //led1 will blink at 0.5Hz (1 sec on, 1 sec off)
    for(;;){
        Slpctrl::sleep( Slpctrl::STANDBY );
    }
}

 

 

Last Edited: Sat. Jul 20, 2019 - 11:06 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

curtvm wrote:
using a compare match only makes sense when you want an irq at some point less than the period, otherwise set period to what you want and use ovf.

Thanks for pointing this out. My thinking was constrained by assuming that the counter overflow value (PER) wouldn't be able to be software defined (I assumed it would be 0xFFFF in hardware and a compare match would be the only way of adjusting the time between sleep and wake). So I thought I needed RTC.CMP and tried to use it on it's own. RTC.PER is great for my needs and that's what I'll use.

 

curtvm wrote:
This simple example will blink an led- the compare match happens at half the period, the compare irq fires, the isr turns on led, then at the overflow the (same) isr turns off the led. Both irq's wake up the cpu from standby.

Thanks. I tried a version of this and it behaves exactly as you described. I can set RTC.CMP with no problems and observe the pulse duty change respectively. So then I tried using just RTC.CMP and no response again. I also tried clearing RTC.INTFLAGS = RTC_OVF_bm at the same time as RTC_CMP_bm but no joy. As I mentioned, I'm thankful that you have confirmed the best way is to change RTC.PER but as this thread is about sharing and discussing observed behaviour in the 402, I think it's worth looking into. I'm sure someone with better experience in setting up controlled tests on these chips will be able to recreate the principle of the test (check if RTC CMP interrupt can work without RTC OVF being set) but I agree that with adjustable RTC PERIOD, its unlikely to limit people, once they are aware the best way to vary RTC-based sleep/wake durations is with the OVF and PER.d

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

smerrett79 wrote:
I also tried clearing RTC.INTFLAGS = RTC_OVF_bm at the same time as RTC_CMP_bm but no joy.

 

You are supposed to configure RTC.INTCTRL so that the OVF bit is cleared. Are you saying this is ignored?

Last Edited: Sun. Jul 21, 2019 - 10:15 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> So then I tried using just RTC.CMP and no response again

>(check if RTC CMP interrupt can work without RTC OVF being set) 

 

I'm still not quite sure what you after, but the compare match and the overflow are two separate things. The only relationship is they both use the same clock, counter, period, and isr vector. When the period matches the counter, then ovf is set and if ovf irq enabled (and global irq enabled) you jump to the isr. Same thing for cmp, except the compare register is used for the match to the counter.

 

If want to use compare only, you can set period to the same value as compare-

    Cpuint::set_func( Cpuint::RTC_CNT,
        [](){
            rtc.flagclr( rtc.IRQ_CMP );
            led1.tog();
        }
    );
    //default 32kint
    rtc.stdbyrun( true ); //required to be a wakeup source from standby
    rtc.irq( rtc.IRQ_CMP, true );
    rtc.period( 32768/2 - 1 ); //0.5sec
    rtc.compare( 32768/2 - 1 ); //same
    rtc.on( true );

    Cpuint::on( true ); //global irq on

    //led1 will blink at 1Hz (1/2 sec on, 1/2 sec off)
    for(;;){
        Slpctrl::sleep( Slpctrl::STANDBY );
    }

If I had left period as its default 0xFFFF, I would then be getting a toggle once every 2 seconds- the toggle happens 1/4 of the way into the period but still only occurs once every period.

Last Edited: Sun. Jul 21, 2019 - 10:32 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

curtvm wrote:
I'm still not quite sure what you after

Don't worry - I was after a periodic interrupt in standby mode that would wake the device, with adjustable duration. Thanks to you and El Tangas making me think it through, I realised that my thinking was along the lines of timer-n CTC for the old ATtinies, where the OVF value wasn't configurable with PER (AFAIK - just based on all the applications I've had), isn't relevant to the 0 series with adjustable PER.

 

What my naive brain was expecting to see was a shortened period between the start of the loop and the impact of the ISR(RTC_CNT_vect) with a smaller CMP. I say naively because I now realise that RTC.CNT doesn't care a jot when the loop code begins and will keep running to PER, thus creating our period that doesn't change when RTC.CMP is changed. If I add RTC.CNT = 0x0000; to the ISR to reset the RTC counter, all of a sudden the period between ISRs shortens and demonstrates that my earlier write to RTC.CMP was successful. 

 

Thanks for your patience - I will amend the OP shortly so as to point people to the way 0 series RTC interrupts need to be thought about, relative to older ATtiny chips' timers.

Last Edited: Sun. Jul 21, 2019 - 10:57 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

El Tangas wrote:
You are supposed to configure RTC.INTCTRL so that the OVF bit is cleared. Are you saying this is ignored?

No, it wasn't ignored - I was thinking wrongly about the expected output of my test code. See reply to curtvm above for detail. All sorted now - I understand why it wasn't producing the result I was expecting and the chip seems to be doing exactly what the datasheet says it will.