STspin32G4 support

It looks like a very nice driver. 9x9mm is a bit big for the boards I’m working on right now, otherwise I’d consider using it right away. Nice find. Must be fairly new, but I missed the announcement…

Just based on the block diagram of the way it is set up I’m going to take a bet that it will work with the standard generic G4 core, G431VB variant. I don’t know if there could be problems flashing and with OpenOCD recognising the chip variant, but in terms of the architecture it is just a “normal” G431 with a 3-phase gate driver in the same chip package. The gate driver communicates with the MCU using the normal “pins” (internally connected, of course).
So it should really just work.

I’ll give it a try in a design sometime soon, but for the moment I need to finish the ones I’m working on first!

I agree, there are some internal i2c going on. It should work like a standalone MCU, but merged.

Then there is the joker, which should most likely reside in a hardware specific folder or maybe it is to intrusive with regards to the algorithm:

CORDIC mathematical hardware accelerator for trigonometric functions

The CORDIC is actually incredibly simple to turn on, having only three registers in total: the control register, data in, and data out. However, making these registers work turned out to be incredibly, incredibly frustrating, mostly because I had never worked with q1.15 format before. But eventually the registers succumbed and the CORDIC gave reasonable answers. I chose to use the CORDIC in 16-bit mode, because that is precise enough for what I need to do. Additionally, 32-bit mode requires two sequential writes to the same register, which is weird. Source: brushless.zone

If you look at the ST dev board for the STspin32G4 it is set up for low side current sensing. Not that is has to use that approach, but it can, using the onboard comparators and opAmps.

I looked at using the STM32 CORDIC - it wouldn’t be easy to integrate…

I’m no expert in math, but ST state a X5 speed doing motor calculations compared to software implementation. Not saying it is easy, but for sure there is a potential for faster calculations and thereby freeing up the MCU. Maybe sometime in the future.

ST apparently has its own FOC algorithm. Does it implement the CORDIC, is it up for grab’s?

https://www.st.com/resource/en/application_note/dm00614795-getting-started-with-the-cordic-accelerator-using-stm32cubeg4-mcu-package-stmicroelectronics.pdf

is a really painful way to drive yourself insane.

@Valentine

Like I said, I looked at it, and it seemed like a complicated proposition to me:

  • it works on fixed point numbers, not floating point
  • it can have up to 24 bit precision, so that would be ok, but to get there requires running the CORDIC for many iterations - so the speed gains are better when you don’t need precision
  • it is a asynchronous peripheral with no Arduino support whatsoever - you’d have to interact with it using only registers or HAL functions.
  • Its performance is optimised in combination with interrupts, or even better, DMA - but calls to trig functions are embedded in streight procedural code, so there would be no easy way to make this asynchronous. You’d be polling for the result.
  • There’s also no compiler or libc/math level support for this. Ideally you’d want to call sin() or cos(), and have the compiler know about the asynchronous CORDIC calls, and reorder code to parallelise it while the CORDIC does its job…

So to use the CORDIC in a minimal way you’d have to implement CORDIC-polling versions of the trig functions, and a bunch of carefully written conversion code to convert arguments from floating point to fixed point representations.

To use it properly you’d have to completely re-write the algorithms to (at least partially) use fixed point math and operate in an asynchronous, interrupt or DMA driven way.

None of this is very “Simple” so from my point of view, while cool, I think it’s out of scope for SimpleFOC. If the people at stm32duino make CORDIC versions of sin() and cos() that we can just easily use, that would be a different thing… but as it stands, I think it’s out of scope for us.

1 Like

Although I agree with the fact that it is mind bending, it is not true that it is “forever” forbidden for SimpleFOC to use the actual analog values. It would not become less simple for the average user to use, since most of the stuff in the algorithm is already mind bending. So if some dude came along and made it work. I believe it could exist parallel to the floating one.

STMicroelectronics STSPIN32G4: Symbol, Footprint, 3D STEP Model | Ultra Librarian

This is how I imagine a modular approach looks like. The POWER_STAGE is separated for optimal cooling of the MOSFET´s, mounted to a cooling surface.

With inline current sensing, using the STspin32G4 4MSPS ADC and a fast PWM immune sensor.

Work in progress…

Bulk capacitors shall be mounted directly on power lines. Maybe in some 3D printed enclosure for water sealing. Since bulk capacitors has a limited lifetime, it makes sense to detach them from the PCB.

2 Likes

Let’s revive this thread. The STSpin32G4 is simply too awesome to not revive.

@runger how far are you with this MCU? I’m thinking to copy the way STM does the SCREF divider (short circuit protection) w. 22K and 10K resister (approximately 1v ref. What’s your thoughts on this. I’ll find room for a solder bridge to disable it, but why would one do that. Do you see any reason to not have it turned on ?

Im hoping to order this week.

My design is mostly done schematic-wise but I still have quite a few calculations to go over. That would include the SCREF :wink:

I put in the CAN-bus, you convinced me :slight_smile:

I’m also starting to look into the layout, but I haven’t fully decided the size I’m going for on this one…

I’m also thinking about manufacturing it with 6 Oz outer copper, I can still do traces down to 8mil in that. But to make that economical I would have to do a panel with more boards in it…

So basically I don’t think I’m going to be ready to order this week :laughing:

A question for you: this type of bus-bar
image
Do you have a component reference for that? I’m trying to find components like that but aren’t finding too much… or is that a feature the Fab does for you when making/assembling the PCB? Or is the intention users add it themselves?

I will get to work on a driver for it soon! Any feature requests? (but not the CORDIC! :laughing:)

Yes, those are rods for welding. They come in different compositions, but some are mostly copper.

Good thing to implement CAN. Down the road it will be wise.

Hmm :thinking: maybe it’s best if I just publish the schematics, that way you can see what I’m up to. Nothing fancy. I will integrate a 4th half-bridge though, like I mentioned, on TIM8.

1 Like

For the record, this iteration is a continuation from another thread. It seams I have taken some large de-tour in order to reach this physical manifestation. Anyhow, I believe I have sketched up something useful, although there are some uncertainties, like will the buck-converter to LDO step-down work as expected.

I have chosen to add a external 3.3v LDO for external use and for the ANALOG domain. This means the internal LDO will supply the IO domain and all other MCU stuff, clock etc. The reason for doing this, is to not over-burden the internal LDO, which has a 120mA limit. Furthermore I have chosen to put a 5V LDO in between the buck and the internal LDO in order to avoid too much heat. Doing this we can maybe turn up the buck voltage to eg. 14v and still be in the zone.

I still have some doubt about the clock, since STM uses a 24MHZ crystal in their reference design. Is this the same for the B-G431B-ESC1? The 32.768 clock pins is right next to the ones STM use, so choosing that approach is not an issue…

EDIT: If HALL sensors are used for motion-sensor purposes, then the SPI pins on the dual-row headers should be used and set up w. pull-ups etc. on the daughter-board/power-stage. The CAL_MT6835 pin is placed on PC5 which has ADC2_IN11 (slow analog input). With this pin, the motor temperature can be monitored, if using HALLs that is. Power-Stage thermistor is broken out on a separate pin w. ADC2_IN5 (PC4 - fast analog input).

Schematics can be found here;

Juanduino/STSPIN32G4-FunQi-Stack: SimpleFoc Format Dev. for potential 8pin PWM stepper use w. 4th half-bridge (also 6pin PWM BLDC use w. extra FET driver for eg. brake-resistor) (github.com)

1 Like

Regarding the Clock source; there is a internal 32 KHz and 16/48 MHz clock. The internal 32 KHz clock “only” has 5% precision, so placing a external 32.768 KHz clock is a option. The internal 16 MHz clock has a precision of 1%. I’m guessing STM is using the external 24MHz clock for PWM generation / tick counting ? Setting up the Advanced Timers TIM1 and TIM8 would then require an appropriate divider etc. Maybe the internal 48MHz clock is used.

Usually the 32.768 KHz clock is used for real-time purposes, eg. in a watch. Do you see any need for that in our use case?

TBH I think you’re fine putting nothing at all.

The low speed oscillator is needed in the low power mode, and 5% isn’t very good so devices that need to follow time and wake up after a reliable delay would include an external low speed clock. I see no need for it on a motor controller.

The high speed oscillator is needed when the chip is not in sleep mode, and is used to feed all the other clocks (of which there are many) in very complicated configurable ways. You can use any value you want within a certain range, as the actual (generally higher) MCU master clock frequency is generated via a PLL circuit in the chip.
If this clock is imprecise there can be problems with fast protocols like USB. But I would assume that 1% is sufficient and USB will work with just the internal oscillator.

One of the big advantages of using the same clock configuration as (for example) the Nucleo board for the same chip (in this case the G431 core it uses) is that you can use the board description files for that board. If you change the clocks you have to define your own configuration.

Ok well then 24MHz it is :stopwatch:

Regarding SCREF: They set this to a fixed 1V level in their application example. I thought this was for over-current protection, but it’s not, it checks against shorting to ground. So maybe leaving it as they suggest is fine, or maybe it can be made settable… I’m considering doing this:

image

if I find I have a spare DAC pin left after the other stuff. Then I can set it from the MCU using its DAC feature, or just set it to output HIGH to disable the protection. Same component count as the resistor divider…

Yeb, it apparently has several sensitivity settings in its register. At first I thought it was the activation (voltage limit) that would trigger this safety feature, like if the 3.3v went below 2.8v or whatever caused by a short, but it is something more sophisticated. It might actually save a otherwise burned MOSFET…

Ok, this is the pinout I have settled on, I hope there are no errors.

I used the G431VBT as basis, and locked all the unconnected pins as outputs (marked X).

I used all the pins on the STSPIN32G4 and have the following:

  • SPI bus for sensor, alternatively same pins support an hardware encoder or hall sensors on TIM3
  • internal SMBA bus
  • external I2C bus + interrupt/wake
  • CAN RX,TX and enable
  • USB
  • UART Serial (will route this to the SWD header for connection to PC via ST-Link)
  • SWD
  • SCREF DAC output
  • current sensing
  • voltage sensing for phases and Vbus
  • 2 LEDs
  • 2 I2C address selection pins (or general inputs)
  • 1 IO, general purpose
  • NRST, BOOT0 (with CAN_RX)

For BOOT0 my strategy is to keep the CAN chip disabled via pull-up during power-up, and only enable it by the MCU after boot. In shutdown mode the chip keeps its RX and TX lines in high impedance. I have made the pull-down resistor on BOOT0 very high-valued, and omitted putting a filtering capacitor on it so as not to stress out the CAN_RX.

2 Likes

Sweet, I will try to play around with the STM32CUBE_MX, first time creating such a project.

Since I do not intent on using the COMP etc. for current sensing, but rather rely on external inline bi-directional PWM immune sensors, the setup will look a bit different. This choice mainly comes down to minimizing pin-count on the bottom dual-row headers. As I understand it CUBE_MX generates some basic init file(s) ?

In ADC1 there appears to be a internal temperature sensor (thermistor). Did you activate that ?

It generates a bunch of code, but all based on STM32s HAL. Not so much use for Arduino framework. But you can use their clock setup function if you correctly configure all the clocks…

But it’s invaluable to do and check the pin assignments. Otherwise, with so many pins it’s very hard not to make mistakes.

If you want to use similar pins to mine then it will be easy to share code later, but its not a big deal if the pins are different either.