Found problems with UNO R4 test_RTC

Hardware UNO R4 UNO R4 WiFi
1

From the IDE 2.1.1 > File>Examples>RTC (Examples for Arduino UNO R4 WiFi) I loaded "test_RTC". I compiled and uploaded it and all I got was this: nothing! A close look at the program revealed that "Serial.println()" was used in 2 interrupt routines: 'periodic_cbk()' and 'alarm_cbk()'. I removed those and replaced them with different logic but still I got nothing out... I strongly suspected that the the "const int LED_ON_INTERRUPT = 22;" was the culprit... so I change that from '22' to 12 and put a resistor/led on port 12. I was not sure that '22' was a valid port on UNO R4, '40' is a valid port and the LED_MATRIX is accessed via some port... After the change, "Bingo!", it all started working as I expected.
The changes I made are listed below:

#include "RTC.h"

const int LED_ON_INTERRUPT  = 12;
volatile bool periodic_int = false;
volatile bool alarm_int = false;

void periodic_cbk() {
...
//  Serial.println("PERIODIC INTERRUPT");
  periodic_int = true;
}

void alarm_cbk() {

//  Serial.println("ALARM INTERRUPT");
  alarm_int = true;
}
...
void loop() {
  static bool status = false;
  if(periodic_int) {
    Serial.println("Periodic interrupt.");
    periodic_int = false;
  }

  if(alarm_int) {
    Serial.println("Alarm interrupt.");
    alarm_int = false;
  }
...
2

Was the original this code?

Callbacks aren't necessarily interrupts.

3

Earlier I opened an Issue about the hang like this.

Serial.print() - from Interrupt callbacks hangs the processor. · Issue #38 · arduino/ArduinoCore-renesas (github.com)

But later closed it as, several up here stated it was by design... However simple fix. Simply raise the priority (lower value) of the Serial ISR.

That is: on my machine I changed cores\arduino\IRQManager.cpp: line 14:
#define UART_SCI_PRIORITY 6 //12

Which allows it to preempt most IRQs except maybe SPI Master. Could raise it again to 2 or 3 to maybe get it to allow prints in SPI masters IRQ handler as well.

4

You are right, callbacks aren't necessarily interrupts. In fact they are not interrupts at all BUT they could be called at interrupt level and it certainly looks like it is called back at the interrupt level in this case. If only the port '22' is replaced with '12' (or any port between 2 and 12) and the rest of the code unchanged, then for output you get:

RTC is running
Current time: 26/7/2023 - 10:57:1
P

The 'P' is the first letter of the 'Periodic interrupt.' string that periodic_cbk() is trying to output, and is now waiting to output 'e'.

1 Like
5

KurtE,
your solution is a little too bold for me. I'll stick with no Serial output during interrupts. What if you are in the middle of Serial I/O from the 'loop' and an interrupt occurs that wants to do Serial I/O?