Problem with Arduino R4 UNO

I am trying to use simpleFOC on my UNO R4, I can input my code directly to the R4 but the motor won’t move and made some electiccal sound. Then I tried to add the PR from (Support Arduino UNO R4 Minima and WiFi - PWM by runger1101001 · Pull Request #289 · simplefoc/Arduino-FOC · GitHub) To the librery, i will receive a error massage in the Serial Monitor:

Firmware name: "C:\Users\User\AppData\Local\Temp\arduino\sketches\4DD59D3D067528632402041D653DDED4/q.ino", compiled on: Jul 27 2023

Fault on interrupt or bare metal(no OS) environment
  addr: 20007e90    data: 000117c9
  addr: 20007e94    data: 0000c97f
  addr: 20007e98    data: 20000358
  addr: 20007e9c    data: 20000f20
  addr: 20007ea0    data: 200002f8
  addr: 20007ea4    data: 20000f20
  addr: 20007ea8    data: 200005dc
  addr: 20007eac    data: 0000c9dd
  addr: 20007eb0    data: 200004cc
  addr: 20007eb4    data: 20000358
  addr: 20007eb8    data: 200002b8
  addr: 20007ebc    data: 00004243
  addr: 20007ec0    data: 00000000
  addr: 20007ec4    data: 00004040
  addr: 20007ec8    data: 0000a500
  addr: 20007ecc    data: ffffffff
  addr: 20007ed0    data: 20003064
  addr: 20007ed4    data: 0000cd91
  addr: 20007ed8    data: 000120a2
  addr: 20007edc    data: 40046f00
  addr: 20007ee0    data: 00000000
  addr: 20007ee4    data: 0000cdd3
  addr: 20007ee8    data: 000120a2
  addr: 20007eec    data: 000078f3
  addr: 20007ef0    data: 000120a2
  addr: 20007ef4    data: 0000ab4b
  addr: 20007ef8    data: 0000ab41
  addr: 20007efc    data: 00002599
=================== Registers information ====================
  R0 : 00000000  R1 : 00000000  R2 : 40078300  R3 : 00000000
  R12: e000e106  LR : 0000f76f  PC : 000000c0  PSR: 41000010
Usage fault is caused by attempts to execute an undefined instruction
Show more call stack info by run: addr2line -e "C:\Users\User\AppData\Local\Temp\arduino\sketches\4DD59D3D067528632402041D653DDED4/q.ino".elf -a -f 000000c0 0000f76e 0000c088 0000c088 0000c97e 0000c9dc 00004242 0000cd90 0000cdd2 000078f2 0000ab4a 0000ab40

Would this be my arduino software proplem?

Sorry for the terrible typesetting, didn’t notice it…

Hi @Test123 , and welcome to SimpleFOC!

Hmmm… is this on a UNO R4 Minima or R4 WiFi?

Are you sure the environment is set up correctly? Is this on ArduinoIDE or on PlatformIO?

The UNO R4 support is very new, so there could still be some bugs and problems. But this one looks more like something isn’t setup right - executing an undefined instruction isn’t something that should be caused by a bug in the simplefoc code, but more like a compiler error.

1 Like

Hi @runger, Thank you for your reply.
I am using R4 wifi with IDE.
I’m not sure what do you mean by environment set up but i’m using SimpleFOC Shieldv2.0.4, SimpleFOC library 2.3 with the R4 PR, the newest version of Arduino IDE and the code that works on Arduino Mega or R3.
However one of the code I use for testing encoder that has include SimpleFOC library in it works well and doesn’t have the error massage. Once I add any code related to motor or driver it will show the error massage again.
Have also tried run the code on other pc, got the same result…


Have you applied just the UNO R4 PR to the master branch, or are you using the dev branch?

It would probably be good to use the dev branch…

I’m not at my computer this week but I will look into it as soon as I can

It is possibly the same as this issue:

It has a similar message in logs:

Fault on interrupt or bare metal(no OS) environment
===== Thread stack information =====
  addr: 20007e28    data: 00017915
  addr: 20007e2c    data: 0001772f

If it is then you may need to wait until 1.0.3 of renesas core is released (assuming the fix makes it into that release). You could also try an older version - perhaps this is a regression.

I still have the problem after update to ArduinoCore-renesas 1.0.4… I will have a try on dev branch today.

Hey @Test123,

For sure you have to use the dev branch for the moment if you want to use the UNO R4. The code for the Renesas MCU it is using is not yet in the release version of the library.

On the R4 Minima it is working for me.
On the R4 Wifi there is a problem, it crashes.

There seems to be a difference in how the R4 Wifi is using the framework that causes this error.

I’m looking into it.

Hi Richard,

Am online :-)… I have good experience in doing isolation of problems as a bug tracking practice.

So, if I have - for instance - 40 almost identically looking code pieces, then I would try to temporarily comment them out and see if it still crashes.

Then I would go over the code, first in large blocks, like: Removing one major function call, then if code still crashes, instate that one again and remove another major function call. Thereby one can oftenly in very few minutes eliminate causes.

If it, however, is a reentrance problem, then that tactique is rarely working.

Can you in any way educate me a tad little bit on how the timer stuff is working?

If I get you right, from the thread above, and from your message on the Arduino forum, then the timers are setting the output directly?

That is - no need for any digital/analog write. One could say it is similar to analogWrite(), where you are controlling the cadence of the output yourself by modifying frequency and duty-cycle.


Hi @davidsvarrer , welcome to SimpleFOC :slight_smile:

Yes indeed, the timers are being used in a way similar to analogWrite(), in PWM output mode. There is no need for interrupts or asynchronous code in this setup, it’s just the timer peripherals of the MCU directly outputting PWM to the timer pins. The duty cycle and frequency can be controlled by writing to the timer registers (via the FSP functions in the case of Renesas).

I have to say, Arduino isn’t exactly making it easy to collaborate with them :frowning: looks like they have a rogue GitHub admin…

They locked the first issue I created, leaving me unable to comment any more on it, and then immediately closed a second issue I created, leaving a threatening note. So it looks like I’m left with no way to report on the bug, through no fault of my own… they also took the measure of just deleting the whole “Discussion” option in github, presumably because they didn’t like our discussing there?

Anyway, I find this very problematic behaviour, I didn’t do anything wrong (neither did you!). I’ve complained to Arduino support about it, let’s see what happens.

For anyone interested, there seems to be a bug with the R4 Wifi timer setup, either on my side or the framework side, not clear. But the same SimpleFOC code is working on the R4 Minima and not on the R4 Wifi, which does suggest there is at least a difference in the framework between these two models.

I’m trying to get support here:

and here: [R4 WiFi vs Minima, Timers] using timers causing crash on R4 WiFi, part 2 · Issue #146 · arduino/ArduinoCore-renesas · GitHub
but Arduino seems more intent on “moderating” the conversation than helping out. :frowning:

1 Like

To keep track of the situation around the R4 WiFi, I’ll add my notes here. I guess no one is really using Renesas MCUs here yet, since we only just started supporting them, but perhaps someone will stumble across this and be able to help out :slight_smile:

  • the problem occurs on R4 WiFi, but not on R4 Minima
  • the MCU hard-crashes, shortly after initialising the timers
  • the crash occurs asynchronously, also if the main loop is in a blocking loop ( while (1); )
  • the stack contains, among other stuff, a reference to the agt_int_isr (AGT interrupt handler) and a corrupted stack entry at the top:
  • the crash occurs independently of whether I start the timers or not
  • the crash occurs only when I use GPT timer channels 2-8, but not for channels 0 and 1
  • the crash occurs whether or not debug output via Serial is enabled or not

My current hypothesis is that the agt timer interrupt is somehow being called for the GPT timers, there is no irq handler set for these, so it jumps to 0 and crashes
Not sure why that would happen though.

Also not at all clear why it would happen on the R4 WiFI, and not on the Minima, so perhaps it is not the best explanation after all :frowning:

Regarding the timer channels, the difference between GPT channels 0/1 and 2-8 is that CH0 and CH1 are 32 bit timers, while CH2-8 are 16 bit. So perhaps the crash would eventually occur on channels 0/1 as well, but it just takes 2^16 times longer to happen.

Sorry to hear that, probably they are playing catch up and are more than a little stressed, alas… I don’t agree with the approach Arduino is taking these days. They have contributed enormously to the community but are trending in a troubling direction recently.

I don’t know anything about that, and it’s unclear to me whether the person is actually involved with Arduino or “just” a contributor. It doesn’t really matter I guess.

I think they have contributed a lot to open source, and the “maker community”. Also, they make some pretty nice boards, and they deliver them to my door within 48 hours of me ordering. That’s pretty good.

In the end, I would just like to post my bug, and track progress on it. I really don’t think I did anything wrong here, and find it hard to understand why they’re making it impossible for me to help them, which is in the end what I’m doing when tracking down this bug. Perhaps they’re motivating me to find the solution by myself :wink: Maybe they don’t want issues that don’t come with a PR ready to go.


Those are PRs, not issues IMO :zipper_mouth_face:
I read the issues too, it seems like the issue was moving quite too fast for anyone upstream to keep track of, but closing the issue made no sense…

Dear Runger and Anthony Douglas, I have - anonymously for you guys - raised the issue about this behaviour with the group management of Arduino, by the so called “invited contributors” on the Arduino site. I share your view that it is highly likely someone who have grown a big head for maybe having been promoted to be a contributor.

In my view, I think the point would always be to keep a problem and the dialogue about it, coherent and together.

In my view, if I was configuration manager with Arduino, I would split the problems up into the problem related to the SIMPLEFOC library/software and the problem related to if the timer is making problems in the Arduino UNO R4 Wifi - compared to the other one where it works.

Thereby the dialogue related to the Arduino core library would take place, there, and the dialogue related to simplefoc would take place in its own forum.

And - every time there is a “spill over” from one leg/branch to the other - it would happen within the same repository.

It is my take, that until it is proven that the bug is not from the library - since it is identifcal code which runs differently on the two almost identifcal R4 platforms - then it is indeed a relevant topic to discuss on the R4 library github.

Well. That was not the take of the invited contributor Per1234 from Arduino - so let us see. I find it offensive the way he was talking and threatening (we call it “shouting”) - that is uncouth, and should not happen in a forum with adult, highly educated, considerate and professional contributors like all of us.

Let peace bestow the fora, and let these rogue individuals (Per1234 et al) find their bearings without threats and similar nonse.

Good news on the actual issue :slight_smile:

Thanks to the help of Arduino the UNO WiFi is no longer crashing! This code is merged to the dev branch, and will be part of the next release.


This guy who works at Adafruit and blogs about open source hardware discusses some of the recent changes at arduino, the post was in july so pretty recent. When Open Becomes Opaque: The Changing Face of Open-Source Hardware Companies « Adafruit Industries – Makers, hackers, artists, designers and engineers!

Not sure this is the best place to post this but I seem to be having some bug with the Dev branch on the R4 Wifi. Using the full control example with MotionControlType :: angle and the commander to set position targets works great but when I force the motor to have an angle error it runs away uncontrollably and unrecoverable. Same sketch on the R3 works as one would expect. The PID loop fights back and corrects the error. Using the same hardware and simpleFOCSheild on both.

I also have a haptics texture sketch I am messing around with on both using TorqueControlType::voltage and that seems to work with no issues.


thanks for reporting it! We seem to have a hard to find bug relating to this, several users have reported similar problems in different setups and situations. It does seem to be related to the more advanced modes like velocity and position modes.

If you can narrow it down any further, it would certainly be helpful. It’s something that affects only some users / setups, so it is proving hard to find.

Which type of sensor are you using?

Setup 1 is an iPower GM4108-120 with an AMT 103 encoder as the sensor.
Setup 2 is an iPower GM5208-12 with an integrated AS5048A running SPI as the sensor.
Both are using FOCshields V2.0.4.

Both run as expected on an R3. You can force the motor to a large angle error (> 1.5 radians) and it corrects with no issue. On the R4 they both respond to commands great and can correct from small angle errors but anything over say 0.05 radians it runs away uncontrollable in the direction of the error. Commanding a new angle during runway does nothing. Even if you set the new target out ahead of the direction its running. I have not found away to get it out of that state.

Below is the basic code I am using. I update the sensor type and associated code when going between encoder and mag SPI.

Please let me know if there is any other info that would be helpful or if there is anything you want me to try out.

#include <SimpleFOC.h>

// BLDC motor & driver instance
BLDCMotor motor = BLDCMotor(11);
BLDCDriver3PWM driver = BLDCDriver3PWM(9, 5, 6, 8);

// encoder instance
Encoder encoder = Encoder(2, 3, 2048);

// Interrupt routine intialisation
// channel A and B callbacks
void doA(){encoder.handleA();}
void doB(){encoder.handleB();}

// angle set point variable
float target_angle = 180;
// instantiate the commander
Commander command = Commander(Serial);
void onMotion(char* cmd) { command.motion(&motor, cmd); }

void setup() {

  // initialize encoder sensor hardware
  encoder.enableInterrupts(doA, doB);
  // link the motor to the sensor

  // driver config
  // power supply voltage [V]
  driver.voltage_power_supply = 12;
  // link the motor and the driver

  // aligning voltage [V]
  motor.voltage_sensor_align = 3;

  // set motion control loop to be used
  motor.controller = MotionControlType::angle;

  // contoller configuration
  // default parameters in defaults.h

  // velocity PI controller parameters
  motor.PID_velocity.P = 0.2f;
  motor.PID_velocity.I = 10;
  motor.PID_velocity.D = 0.0;
  // default voltage_power_supply
  motor.voltage_limit = 12;
  // jerk control using voltage voltage ramp
  // default value is 300 volts per sec  ~ 0.3V per millisecond
  motor.PID_velocity.output_ramp = 100;

  // velocity low pass filtering time constant
  motor.LPF_velocity.Tf = 0.01f;

  // angle P controller
  motor.P_angle.P = 5;
  //  maximal velocity of the position control
  motor.velocity_limit = 15;

  // use monitoring with serial
  // comment out if not needed
  //display variables
    motor.monitor_variables = _MON_TARGET | _MON_VEL | _MON_ANGLE; 
    // downsampling
    motor.monitor_downsample = 100; // default 10

  // initialize motor
  // align encoder and start FOC

  // add target command T
  //command.add('T', onTarget, "target angle");
  command.add('M', onMotion, "motion control");

  Serial.println(F("Motor ready."));
  Serial.println(F("Set the target angle using serial terminal:"));

void loop() {
  // main FOC algorithm function
  // the faster you run this function the better
  // Arduino UNO loop  ~1kHz
  // Bluepill loop ~10kHz

  // Motion control function
  // velocity, position or voltage (defined in motor.controller)
  // this function can be run at much lower frequency than loopFOC() function
  // You can also use motor.move() and set the in the code

  // function intended to be used with serial plotter to monitor motor variables
  // significantly slowing the execution down!!!!

  // user communication;