STspin32G4 support

Hi

So ive bumped into the quite awesome STspin32G4, and I think this IC deserves its own thread and support. This is a combined MCU and BLDC driver running 170Mhz. 4MSPS ADC.

The MCU is a STM32G431VBx3, so not exactly the same as on the B-G431B-ESC1, but darn close.

This IC is in a sense a merge of the B-G431B-ESC1 MCU and its BLDC driver (L6387) into a single package.

Its the obvious SimpleFOC candidate.

How is the support on this IC? Have minimal experience programming ST MCU´s, but i see there is a large Arduino Core, where it should be possible to add further MCU support. GitHub - stm32duino/Arduino_Core_STM32: STM32 core support for Arduino

I’d love to make a breakout board for testing, however, I don’t see it stocked at JLC, even the extended parts catalogue does not carry this component. Going through a third party to source for me is a no-go due to my current commitments.

Also, why is this so important to you? A simple two-component board with G4 and another driver would work just fine. What is it about this particular component that makes it so special?

Well, overall it’s just a neat IC for SimpleFoc. It has some inbuilt safety features, since it’s a integrated MCU and driver. It has a build in buck, which by the way can be set up as a buck-boost. 170Mhz will yield a decent FOC iteration freq.

It’s affordable, if you take into account the integrated driver. It’s in stock.

My take on this general shortage situation is to use this time to develop. It’s not like ST is going to abandon the SPIN32 family.

I don’t see it stocked anywhere. Where did you see that? Lead time is over a year, somewhere in mid-2023.

Cheers,
Valentine

That’s in Europe. Here it’s out of stock. You must have a EU physical address and billing to order it from farnell. You cannot buy it, and even if you could how are you going to SMD?

I’m in Denmark.

I’ll solder it in my reflow oven… if I can get arduino support for the MCU.

That’s very risky. That’s a VFQFPN-64_L9.0-W9.0-P0.50-TL-EP4.0 footprint with 0.254mm pins and 0.5mm pitch.
If I get the time, I may create a breakout board, however given my current load, it’s very unlikely anything could happen before June. But I’m warning you, reflowing this pitch at home is a really painful way to drive yourself insane.

The Arduino support should be there, you may try using the G4 branch.

Cheers,
Valentine

That’s within reasonable diy reflow pitch range IMO. If you just use a stencil for the solder paste, no worries.

Where is the G4 branch?

Ah!

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).