NUCLEO STM32H755ZI-Q - Configuration

hardware support
, ,
1

Hi,

Long-time reader (as a guest), first-time poster!

First of all, congratulations on the awesome work you’ve been sharing here. I’ve learned a lot by going through your posts, code examples, hardware solutions, and everything else I could find!

I’ve been extensively testing your project on various MCUs (Arduino UNO, RP2340, ESP32, and Nucleo 144) along with different drivers (Deng Dual FOC, MKS Dual FOC V3.2, SimpleFOC Mini, and SimpleFOC Shield). Everything has gone smoothly using Arduino and PlatformIO IDE.

I’ve also tested the different branches kindly provided by @runger for the exotic boards I have—thanks for that!

Today I decided to level up my project and started working with a NUCLEO-H755ZI-Q paired with two SimpleFOC Shields, but it’s giving me a bit of a headache. I’m confident I’ve set up the hardware correctly (at least for the Shields), and I haven’t modified the Nucleo board yet.

However, I’m encountering two main issues and was wondering if anyone might have some insights:

1. After successfully flashing the board multiple times with working scripts (including blinking LEDs and serial communication), my board suddenly locked up, preventing me from reflashing any previously working scripts. I suspect it might be related to the issue discussed here:

https://www.stm32duino.com/viewtopic.php?t=2550

Before diving into creating a new configuration file for the H755ZI-Q—which doesn’t seem to exist yet in STM32Duino—I was wondering if anyone here has already faced this issue?

2. At some point, I managed to flash the board with the SimpleFOC open-loop position control, which previously worked fine on other MCUs. However, the driver wouldn’t supply power to the motor. I suspect it’s related to pin configuration. Since I’ve noticed a few posts from members who worked with STM32H7 MCUs, I thought I would ask if anyone had suggestions or specific points I should verify.

I can provide my code, though it doesn’t differ from what’s available on GitHub.

Thanks again for your great work. I’ll continue investigating while looking forward to your feedback! :slight_smile:

2

Hi @GregOb , welcome to SimpleFOC!

Working with the H7 dual core series is a little tricky, but I have a working setup and can share details with you. I hope that will solve your first issue.

You’ll need the dev branch of the library from GitHub where I have recently merged the H7 support to our STM32 driver.
That should solve your second issue.

Do you have a GitHub user?

3

Hi @runger, Thanks for your quick answer!

I do have a GitHub account.

I think I’ve checked one of your STM32 HAL branches but I’m unsure it was the right one! I’m more than happy to look at your work and let you know how it went for me.

For now, I’ll probably use only one Core from it as I’m planning to use the second for other things.

As soon as problem 1 is solved I will get back to the dev branch and try to make it work.
I also figured that the pinouts proposed by my Arduino-compatible pins from the Nucleo board do not offer enough PWM pins with a shared timer.
I may have only 1 shield able to work from being plugged in the Nucleo. The second shield will have to be wired to the proper Nucleo’s pins.

I will keep you posted on how things are going!

4

Hey,

At this point I’ve merged that HAL branch into the dev branch of the library, so that is the one I would recommend for now: GitHub - simplefoc/Arduino-FOC at dev

If you’re interested you can DM me your GitHub user and I can invite you to some repositories in which I was testing the H757ZI setup.

5

I’ve just sent you an email. Looking forward to check your repo.

6

So it seems that after reflashing the board using STM32CubeIDE example, and turning the CM4 to sleep, the board is back up and running !

I have decided to re apply SimpleFOC using dev branch and given example.

#include <SimpleFOC.h>

#define SERIAL_PORT Serial3  // Use USART3 (ST-Link Virtual COM)


// BLDC motor & driver instance
// BLDCMotor motor = BLDCMotor(pole pair number);
BLDCMotor motor = BLDCMotor(7);
// BLDCDriver3PWM driver = BLDCDriver3PWM(pwmA, pwmB, pwmC, Enable(optional));
BLDCDriver3PWM driver = BLDCDriver3PWM(6, 5, 3, 4);

//target variable
float target_position = 0;

// instantiate the commander
Commander command = Commander(Serial);
void doTarget(char* cmd) { command.scalar(&target_position, cmd); }
void doLimit(char* cmd) { command.scalar(&motor.voltage_limit, cmd); }
void doVelocity(char* cmd) { command.scalar(&motor.velocity_limit, cmd); }

void setup() {

  // use monitoring with serial 
  Serial.begin(115200);
  // enable more verbose output for debugging
  // comment out if not needed
  SimpleFOCDebug::enable(&Serial);

  // driver config
  // power supply voltage [V]
  driver.voltage_power_supply = 12;
  // limit the maximal dc voltage the driver can set
  // as a protection measure for the low-resistance motors
  // this value is fixed on startup
  driver.voltage_limit = 6;
  if(!driver.init()){
    Serial.println("Driver init failed!");
    return;
  }
  // link the motor and the driver
  motor.linkDriver(&driver);

  // limiting motor movements
  // limit the voltage to be set to the motor
  // start very low for high resistance motors
  // currnet = voltage/resistance, so try to be well under 1Amp
  motor.voltage_limit = 3;   // [V]
  // limit/set the velocity of the transition in between 
  // target angles
  motor.velocity_limit = 5; // [rad/s] cca 50rpm
  // open loop control config
  motor.controller = MotionControlType::angle_openloop;

  // init motor hardware
  if(!motor.init()){
    Serial.println("Motor init failed!");
    return;
  }

  // add target command T
  command.add('T', doTarget, "target angle");
  command.add('L', doLimit, "voltage limit");
  command.add('V', doLimit, "movement velocity");

  Serial.println("Motor ready!");
  Serial.println("Set target position [rad]");
  _delay(1000);
}

void loop() {
  // open  loop angle movements
  // using motor.voltage_limit and motor.velocity_limit
  // angles can be positive or negative, negative angles correspond to opposite motor direction
  motor.move(target_position);
  
  // user communication
  command.run();
}

And I’m getting this as an output :

STM32-DRV: Timer resolution set to: 4800
STM32-DRV: Configured TIM1_CH1
STM32-DRV: Configured TIM1_CH2
STM32-DRV: Configured TIM1_CH3
STM32-DRV: Synchronising 1 timers
MOT: Init
MOT: Enable driver.
Motor ready!
Set target position [rad]
5.000
0.000

But that doesn’t make the motor rotate… It’s just shaking.
I’m pretty sure that my wiring is fine so I’m running out of idea :frowning:

I will keep you posted if things are changing.

I’m not sure whare Time resolution is doing to the code so I may start to investigate with this.

7

Hey, I finally got to it and sent you GitHub invites… I replied to your DM.

8

Thanks a lot. I had a quick look, but I will dig deeper tonight. :slight_smile:
At first, it seems you are assigning pins based on their name, which differs from what STM32Duino library is doing.

I may try adding the H755ZI-Q board configuration to that library so other programmers can benefit from it. Is there anything I should take into consideration while doing it?

9

It’s quite a complicated board to add because of the dual core and the power supply options. I guess you could assume the default config for power, and only enable the one of the two cores… that would be easier, and would be the same level of support as the other dual core nucleos board definitions.

To add it properly is still quite a bit of work. I think there’s one or two tickets related to that in the stm32duino GitHub issues.

I think the main problem is that Arduino itself uses the H7 in the Portenta and Nicla lines, but they base their framework support on the (now-defunct) mbed framework.
Within that framework there is a notion of dual core support and a few primitives for working with both cores.
But in stm32duino there is currently no concept of dual core, no way to link two binaries for the two cores into a single firmware elf file, no abstractions for communication between the cores, etc
So to do a “proper” job of it is still a big task.