Something is still not adding up… you can see the BOM for the nucleo boards on ST’s website, and they are definitely using a ±20ppm crystal, so the stability should be high, at least as good as the R3.
That said I’m not sure what else there is to try here. Assuming your new clock config is setup correctly, there isn’t much else to check. I saw that on some Nucleos the main MCU is driven by MCO out from the STLink, which is using its own HSE but that doesn’t seem to be the case here.
I will try it once more and manually verify the main c code, in Cube IDE, to make sure HSE is chosen. You are 100% correct that the Nucleo should be better. The R3 is so nice, just flash and dash haha!
Like I mentioned to @VIPQualityPost , I will try one more time and verify the code line by line to make sure the HSE is chosen. Might have been a wobble, so I guess I have to be responsible and check it out haha!
How are you actually moving over the clock code into your project?
It puts it into main.c but you can’t compile Arduino framework code in Cube IDE.
I usually hit “generate code” in Cube MX/IDE, then I take the SystemClock_Config function and paste into a new file in my simpleFOC project, then save that file as clock.c. You don’t need to #include the file or anything else.
Here is a clock config for the G474 that uses HSE 24MHz, you can just paste this into a new text file clock.c and put in the same directory as your main.cpp and it should get compiled in (at least in PIO, I’m not sure the behavior in Arduino IDE) :
#include "pins_arduino.h"
/**
* @brief System Clock Configuration
* @retval None
*/
void SystemClock_Config(void)
{
RCC_OscInitTypeDef RCC_OscInitStruct = {0};
RCC_ClkInitTypeDef RCC_ClkInitStruct = {0};
/** Configure the main internal regulator output voltage
*/
HAL_PWREx_ControlVoltageScaling(PWR_REGULATOR_VOLTAGE_SCALE1_BOOST);
/** Initializes the RCC Oscillators according to the specified parameters
* in the RCC_OscInitTypeDef structure.
*/
RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE;
RCC_OscInitStruct.HSEState = RCC_HSE_ON;
RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;
RCC_OscInitStruct.PLL.PLLM = RCC_PLLM_DIV2;
RCC_OscInitStruct.PLL.PLLN = 28;
RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV2;
RCC_OscInitStruct.PLL.PLLQ = RCC_PLLQ_DIV2;
RCC_OscInitStruct.PLL.PLLR = RCC_PLLR_DIV2;
if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)
{
Error_Handler();
}
/** Initializes the CPU, AHB and APB buses clocks
*/
RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_HCLK|RCC_CLOCKTYPE_SYSCLK
|RCC_CLOCKTYPE_PCLK1|RCC_CLOCKTYPE_PCLK2;
RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK;
RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV1;
RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV1;
RCC_ClkInitStruct.APB2CLKDivider = RCC_HCLK_DIV1;
if (HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_4) != HAL_OK)
{
Error_Handler();
}
}
So if I run the program in Cube and flash my G474re, unless I change the Arduino code, it would revert HSI?
Yes!
The clock configuration is part of the compiled program, so if you are flashing a new program (e.g. flashing something from arduino) it will use whatever the clock config is found at that time (for STM32duino, the default clock configs are used, unless a file is used like I mentioned above)
This is the one STM32duino will pick by default for G474RE (note, using HSI)(note the WEAK function binding, so that you can over-write it by including this function in your main program or compile dir) : https://github.com/stm32duino/Arduino_Core_STM32/blob/main/variants/STM32G4xx/G473R(B-C-E)T_G474R(B-C-E)T_G483RET_G484RET/generic_clock.c
Note that this STM32duino framework just takes the defaults from CubeMX (which was why I was checking there earlier)
Hey, at least as far as I can tell the clock configuration for the Nucleo G474 is using the HSE:
So there should be no need for custom clock routines if you choose the right board in ArduinoIDE/PlatformIO.
We’re talking about open loop mode here, correct? In any case, I think these results mean that it is not in fact the oscillator instability that is the cause of the speed instability.
So what could be the cause? One way to make the Nucleo more like the UNO would be to add some delay to the loop - something on the order of 100-200us should result in a loop speed similar to the UNO.
this is a good point - the clock config you posted only is true if -D ARDUINO_NUCLEO_G474RE is defined in the build flags.
What build flags are you using?
I think I’m stumped… but anyway, at least with 401RE (as you have selected in Tools) is using HSI:
Maybe @runger is right there is some other issue. I guess you could do this to see how it’s actually hooked up while the board is running, @dekutree64 did something clever:
https://community.simplefoc.com/t/lepton-deku-mod/2641/30?u=vipqualitypost
Question: with the increased loop speed of the Nucleo, the accuracy of the motor configuration parameters of KV, Phase Resistance, Phase Inductance become more important, right?
With the arduino loop speed, close is ok. But when firing 10x more often with the Nucleo, I would expect pulses to be smaller and thus the accuracy of those values have a larger affect on the pulse voltage/current?
Hey, thanks for all the research, much appreciated. I will try get a handle on PIO as I have never used it and try a few things. Not my jam, but no time like now to learn haha!
Off topic, are you also working on a vinyl turntable? I think you mentioned it before.
Exactly! I think it is this type of effect we’re seeing, and hence the difference in performance.
Another thought: it could be due a difference in how the micros() function is implemented, with the UNO one being the more accurate/stable implementation.
Yes, because the 401RE’s board definition uses the internal oscillator.
To use the external one on this board, you have to re-route the clock from the daughterboard, and then also provide a new clock function that uses an 8MHz HSE.
On the G474, the default configuration uses the HSE, so all you have to do is choose the right “Board part number” in the arduino menu.
When I tune motor resistance (a bit lower than spec) and KV a bit higher, I get very good performance with the Nucleos. I picked up a G474 with the HSE to test, and it is slightly better than the F446. The G474 is also rock solid at the set speed, while the F446 tends to drift faster slightly over time.
I also have a Nucleo144 H723. It does not have an HSE onboard either, and it performs similar to the F446.
I’m still not sure about that explanation, because indeed the accuracy has a larger effect, but the control loop also is running 10x faster, so it should be able to correct for deviations more quickly, I would think?
Does micros() do anything more than just read the value of the systick/main timer? I don’t see how it could be “more accurate” on ancient AVR than state-of-the-art 32 bit MCU… but ST has had their fair share of silicon bugs, I guess…
It’s something I’ve been planning to look into. on the new Renesas UNOs it seems to use interrupts to drive the micros timer. Perhaps that’s just to deal with the overflows somehow.
Yes, but it also means the voltages commanded will be different, and the calculations more prone to error. If the time is shorter, the error will be proportionally higher.
Thanks for the feedback! Is this also in open loop mode?
Yes, open loop. I will try out the stm viewer tool this weekend to capture and measure actual motor performance, to compare it with that RPM app. I plan to test the motor both unloaded and then connected to the platter flywheel.
My approach is to get openloop working as close to perfect as I can, then test out closedloop.
I have a couple motors to try out as well. My standard inrunner 4 pole vs a 22 pole outrunner gimbal (both very similar at 62 KV and 11ohm resistance).
So…finally escaped from the Star Episode “Spock’s Brain” and fired me upmsome synapses, haha! So your code, a million thanks, does work and improves timing once compiled in PIO. The problem now is that the motor squeals like a banshee escaping from Satan’s posterior. I have seen it many times on rc aircraft, and I know it’s timing, but I have no clue where to adjust it.
So speed on the G474re is done with full credit to @VIPQualityPost
Just have fix the motor timing and Nucleo is a ‘Rockin’!!!
