STM32G030 / G031

[ag123]

ok I'm a bit old school
but that AliX vendors are 'storming' the stores with those chips 

Taking a look at STM32G0 series
https://www.stm32duino.com/viewtopic.php?t=1848


https://www.st.com/en/microcontrollers-microprocessors/stm32g030f6.html

https://www.stm32duino.com/viewtopic.php?p=11661#p11661

[ag123]

https://www.stm32duino.com/viewtopic.php?p=12748#p12748

I noted that in the G030 G031 series
https://www.st.com/en/microcontrollers-microprocessors/stm32g0x0-value-line.html
https://www.st.com/en/microcontrollers-microprocessors/stm32g0x1.html

the G031F8 has got a 20 pin TSSOP  chip that has got 64k flash and 8 k sram, those are 'less featured' among the AliX vendors as I'd guess most of them simply stock the G030F6 being the 'cheapest' possibly.
my guess is G031F8 is probably more suitable for C/C++ style development and is less prone to exhausting the flash program storage too quickly, i.e. can take some 'fat' lol.

one of those things I'm thinking of is try to bit bang usb full speed 12 Mbps. These days those usb 'full speed' transceivers are hard to get some of them marked obselete, e.g. the usb1t11a
https://www.mouser.com/datasheet/2/149/fairchild%20semiconductor_usb1t11a-320893.pdf
https://www.onsemi.com/products/interfaces/wired-transceivers-modems/usb1t11a
they literally cost more than microcontrollers for retail chips alone. I'd guess after all, socs with usb built-in are after all common these days and it 'isn't worth' the trouble patching another chip just to do that.

I'm thinking if I could 'abuse' things like the max3485 which purportedly can do up to 10 Mbps, trying to push 12 Mbps for usb full speed signals
https://www.analog.com/en/products/max3485.html
these are fairly abundant and rather low cost
https://www.aliexpress.com/w/wholesale-max3485.html
the idea is to 'drive' the max3485 at 12 mbps on SPI which seemed quite doable.
then for things like 'single ended zero' - a.k.a 'usb reset' , it'd probably take a transistor or try with a gpio pin to pull both the differential line to zero.

an alternative is to directly bit bang usb on the GPIOs and I kind of stumbled on how to generate the differential signals at the GPIOs, hence, looked at the max3485

there is still some incentive to bit bang usb on these 'no usb' chips as it dramatically expand the use cases, just that the small amount of flash and sram is going to prove to be a challenge.

[wek]

> bit bang usb

Just.... why???

JW

[ag123]

> bit bang usb

Just.... why???

JW

well it doesn't have it (usb) 
the 'serial port' of today is simply it - usb

[wek]

Yes, and...

JW

[ag123]

i played with the notion that MAX3485 is my 'USB transceivier'
https://www.analog.com/en/products/max3485.html
a thing is MAX3485 did not define the state at the receiver if both differential inputs are low, what is only documented is
A,B > +0.2v -> 1
A, B < -0.2v -> 0
inputs open -> 1

i'd risk a guess that if A,B is at GND, the input is  '1'  lol
this is needed to detect the 'single ended zero' condition where both differential inputs are low
https://www.beyondlogic.org/usbnutshell/usb2.shtml
https://www.usbmadesimple.co.uk/ums_3.htm
i.e. 'usb reset'

if 'single eided zero' is '1' at the receiver end, i'd guess a way is to probe D+ with gpio that it is after all 0
that would be the host signaling a 'usb reset'

another doubt though is that MAX3485 apparently has some slew rate limiting, filtering, that may have some implications transmitting the signals at 12 mhz and above.

[DavidAlfa]

Why do you need a transceiver for bitbanging USB? Simply toggle the pins?
A 48MHz mcu will not be able to sustain 12Mbps even in your best dreams (Exception: Pi Pico, handling USB with PIO).
So, your only option will be USB 1.0 spec @ 1.5Mbps, at best.

You have several usb projects doing this:
https://github.com/IOsetting/py32f0-template/issues/12

[ag123]

Why do you need a transceiver for bitbanging USB? Simply toggle the pins?
A 48MHz mcu will not be able to sustain 12Mbps even in your best dreams (Exception: Pi Pico, handling USB with PIO).
So, your only option will be USB 1.0 spec @ 1.5Mbps, at best.

You have several usb projects doing this:
https://github.com/IOsetting/py32f0-template/issues/12

a trouble with STM32 is that i've not figure out an 'easy' way to toggle 'complementary' differential signals. the timers can do it but that it isn't quite like transmitting a data stream.
a trouble with usb is that it isn't 'pure differential' as there are additional signals such as 'single ended zero' i.e. both D+ and D- at GND.
so that adds a little more 'complications'


sustaining 12 Mbps with SPI or even higher speeds like 20 Mbps or even higher is feasible. I've tried updating data in a spi flash chip of the Windbond W25Q64BVSIG type SPI flash ram and has been able to do that quite stably at 20 mhz off a stm32f103c8 device.

there is actually an (old) chip that does it well USB1T11A
https://www.onsemi.com/products/interfaces/wired-transceivers-modems/usb1t11a
https://www.onsemi.com/download/data-sheet/pdf/usb1t11a-d.pdf
it is 'made for purpose' - a usb 1.1 full speed transceiver
it perfectly fit the 'SPI' interfacing option.

apparently while this is marked 'obselete', it is apparently still 'widely' in use
https://www.lcsc.com/product-detail/span-style-background-color-ff0-USB-span-ICs_onsemi-USB1T11AMX_C464142.html

it is 'made for purpose', just that in the 'online flea markets' these days
https://www.aliexpress.com/w/wholesale-USB1T11A.html
this 'old chip' practically cost as much as many microcontrollers itself in the 'retail' small quantities markets.

it may still be worth getting though, as practically the large set of the stm32g03x series practically don't have usb, even if some of them have more sram and flash.

another way which is 'common;' is to simply patch a usb-uart chip, e.g. CH340
at 'retail' quantities, a CH340 completely built with a crystal, LDO, usb connector, a 5v, 3v switch, accessories components (smd caps, resistors) + PCB + header soldered can be about 'equal' in price to a single piece of USB1T11A
https://www.aliexpress.com/item/1005004824108230.html
https://www.aliexpress.com/item/1005005272826903.html

but of course with a USB1T11A, one is not limited to 'usb serial', one can practically 'bit bang' any USB protocol e.g. HID and make a keybboard, mouse etc

the other thing is there are probably 'other' chips which bundle a usb function on chip but is probably not in the stm32g03x series.
e.g. stm32f103c8, cost a little more but is probably what it cost to add that usb functionality.

[bingo600]

Hello ag123 

Why would you bitbang USB ??
I'm quite sure i saw one of the new CHxxx USB->Serial chips, that needed no Xtal.

And i know you have a "bag full" of F411's , from when we did wheatstone tests on the 'duino forum

If you need USB, either get one of the new CHxxx , or use a Fxxx with builtin USB.

/Bingo

[ag123]

well, stm32g030* is kind of a 'fad of the moment'
many AliX vendors are stocking them
https://www.aliexpress.com/w/wholesale-stm32g030f6p6.html
not surprising as it is after all 'cheap' costing well less than a dollar
is a 'recent' stm32 series
https://www.st.com/en/microcontrollers-microprocessors/stm32g0-series.html
the TSSOP20 chip can be easily soldered on DIP to SOP20 'adapter boards'
sram is 8k flash is 32k for stm32g030f6p6 - decent
then if one goes for the stm32g031F8 that becomes 8k sram and 64k flash
https://www.st.com/en/microcontrollers-microprocessors/stm32g0x1.html
ideal for a 'keyboard'
just that 'no usb'

it takes to go up to the series numbers STM32G0B1K8 128 KB flash and 144 KB sram
https://www.st.com/en/microcontrollers-microprocessors/stm32g0b1kb.html
then you see USB in there. 144 KB sram to do a keyboard? well what a waste of transistors 

for now the more promising stm32 G* series is the G4 series
a lot of features in a little package
https://www.eevblog.com/forum/microcontrollers/blackpill-stm32g431cbu6-170-mhz-32k-ram-128k-rom-12-bit-adc-and-dac/
but apparently quite different 'use cases' vs the stm32g0 series.

[DavidAlfa]

The problem is not toggling pins at 12MHz, but parsing fast enough, and you must also calculate CRC.
Not all USB is differential, there're states where only one pin changes.

Don't you know how to toggle differential signals in sync?
That's what BSRR allows, setting and resetting any number of pins at once.
Syncing two different SPI peripherals will be much harder (If you have 2 to begin with).
Wasting most mcu resources to make USB makes no sense, you can get actual USB-enabled MCUs for a bit more.

[thm_w]

the other thing is there are probably 'other' chips which bundle a usb function on chip but is probably not in the stm32g03x series.
e.g. stm32f103c8, cost a little more but is probably what it cost to add that usb functionality.

The STM32F103C6T6A is a few pennies more and includes USB hardware. Unless you are making 10 million devices its not worth it.

You can probably source some F103 clones for sub 60c if you want to as well. Just that they are often not code compatible with the STM32F103 in terms of USB (geehy, gigadevices, etc.).

[Sacodepatatas]

You can code for the STM32G031F8P6 and then program the flash binary into an STM32G030F6P6 (using the ST-Flash utility with the option "--flash=64k"). They both have the same die and the only difference is that the F6P6 doesn't have F2 connected to the reset line.

You are right. These MCUs are awesome. I purchased 100 STM32G030F6P6 for about 36€, and they all have the hidden flash and undocumented features (128MHz timer, 16bit hardware oversample ADC...).

[PCB.Wiz]

Wasting most mcu resources no make USB makes no sense, you can get actual USB-enabled MCUs for a bit more.

Yes, the USB addition is 'almost free' on new MCUs these days.

lcsc have STC USB MCUs from 27k/1k TSSOP20 64k

[DavidAlfa]

The STM32F103C6T6A is a few pennies more and includes USB hardware.

Or even the cheaper 101x, which also includes the USB hardware though not officially.

[langwadt]

> bit bang usb

Just.... why???

JW

because then you don't need a usb2serial adapter, and low speed 1.2Mbit is probably plenty what you would do with such a small part

[ag123]

The problem is not toggling pins at 12MHz, but parsing fast enough, and you must also calculate CRC.
Not all USB is differential, there're states where only one pin changes.

Don't you know how to toggle differential signals in sync?
That's what BSRR allows, setting and resetting any number of pins at once.
Syncing two different SPI peripherals will be much harder (If you have 2 to begin with).
Wasting most mcu resources to make USB makes no sense, you can get actual USB-enabled MCUs for a bit more.

BSRR is a good idea and I'd probably try that as an experiment., toggling pins fast can likely be achieved using DMA. Using DMA it is quite likely toggling them at 12 Mhz may be feasible.
Initially I'm thinking of using 'cheap' MAX3485 transceivers to do the job, which according to specs drives up to 10 Mhz, but that the slew rate limiting and filtering is likely to cause signal problems at those Mhz in particular the transmit side.

the idea with SPI is to drive the transceiver the substitute being MAX3485 and the 'real' on is that 'old' chip USB1T11A which is a real usb 1.1 full speed transceiver.
I did some 'thought experiments' and kind of think that driving USB1T11A via SPI and DMA is likely pretty feasible, thereby achieving a full USB 1.1. full speed PHY.
the rest of the 'bit banging' becomes dealing with the protocol stuffing the buffer with USB frames including CRC etc.
I think this is pretty feasible with the stm32g0 or the cortex M0 chips.

Just that USB1T11A  is pretty costly as it is 'infrequently used' costing as much or more than a microcontroller in 'retail quantities'
in fact USB1T11A is deemed 'obsolete', but apparently it is still quite widely used given the availability.

lets just say that we are "stuck" with stm32g0xx (well less that stm32g0b1 which has usb 128k flash 144k sram, sometimes a bit 'overblown' for that sram and extra price)
everyone, what would be a 'nice' plug in for USB1T11A  as a transceiver ? e.g. like MAX3485 - just that this may have serious limits at 10 Mhz and beyond.
basically a differential signalling transceiver

[ataradov]

Toggling the pins is the easiest part with software USB stacks. Receiving the bits is hard.

You can absolutely forget about bit-banging USB FS, it is just not going to happen with a generic MCU.

And as far as transceivers go, it was already pointed out that USB will require single-ended signalling for bus reset and EOP. And in case of USB LS keep-alive signals, but those generally can be ignored.  There is no getting away from SE0 for the EOPs, which you need to be able to receive and transmit.

For USB1T11A you will have to drive VPO and VMO/FSEO pins, so two pins either way, might as well just drive D+/D- directly. If you are adding an IC anyway, just add a USB to serial and be done with it.

[DavidAlfa]

Toggling BSRR with DMA would require:
- Timer to drive DMA @12MHz
- DMA Channel
- 64bytes packet = 512bits, x2 bytes of BSRR = 1KB memory for sending the packet

For a similar price as the transceiver's you can get a usb-serial converter and make your life much easier, but with the added cost, now you can buy a much better mcu.
The only way to justify this is by not using any external parts, again 1.5Mbit/s of the USB 1.0 will be enough for most applications, you have existing software doing so, it's the logical way to go.

[ag123]

for USB1T11A
https://www.onsemi.com/download/data-sheet/pdf/usb1t11a-d.pdf
the truth table in pin descriptions

Code: [Select]

mode 0
VPO   VMO    Result
  0    0     logic '0'
  0    1     /SE0
  1    0     logic '1'
  1    1     /SE0
from here, it is quite visible that VP0 determines the logic '0' and logic '1'. hence, VPO can simply be driven by MOSI out of SPI
and an additional gpio to drive VM0 if you want to signal SE0 (single ended zero) to the host.

then at the receiving end the single pin RCV is the decoded logic '0' and '1', that goes to MISO

additional inputs these can possibly be monitored via GPIO

Code: [Select]

VP    VM    Result
  0    0     SE0
  0    1     low speed
  1    0     full speed
 

it seem fairly complete as a USB 1.1 full speed PHY and the main data streams is driven on SPI which can be in turn driven by DMA.
hence, it'd seem fairly doable even for stm32g0 series chips.

an interesting 'feature' is CLK signal in SPI is 'redundant' maybe a use could be found somewhere for it. my guess is that it may be possible to recover clocks from usb SYNC blocks but that it'd likely be some 'complicated' hardware PLL & all.

[ag123]

while checking out the chips
apparently ST has its own too
STUSB03E USB Transceiver Compliant to USB V2.0 for full-speed (12Mb/s)
and low-speed (1.5Mbps) operation
https://www.st.com/resource/en/datasheet/stusb03e.pdf

STOTG04E USB-OTG Full-speed Transceiver
https://www.st.com/resource/en/datasheet/stotg04e.pdf

just that these are seldom featured in the 'online flea markets' or that they are expensive in the 'online flea markets'.
what is featured in the 'online flea markets' is the 'obselete' USB1T11A  and apparently there is probably a 'moderate' demand for it
https://www.aliexpress.com/w/wholesale-USB1T11A.html

for RS485 transceivers apparently there is the max3460-max3464 series which does 20 msps
https://www.analog.com/en/products/max3460.html
and MAX13450E
https://www.analog.com/en/products/max13450e.html

from ST STR485 3.3V RS485 compatible with 1.8V I/Os and selectable speed 20Mbps or 250kbps
https://www.st.com/en/interfaces-and-transceivers/str485.html

these are seldom featured in the 'online flea markets' or that they are expensive in the 'online flea markets'.
in the 'online flea markets' instead there are a 'bunch' of '485' style chips from various sources, a thing about those '485' chips is if they put some filters or limits the slew rates which would 'handicap' usb performance in the 12mhz ranges, mainly at the transmitting side. accordingly it is to reduce reflections for 'poorly terminated' lines.

so the 'solution' in the 'online flea markets' remains as that 'old' (fairchild) USB1T11A
https://www.onsemi.com/download/data-sheet/pdf/usb1t11a-d.pdf

[DavidAlfa]

for USB1T11A

Costs 2x the STM32. You can get now a MCU with USB.

STUSB03E USB Transceiver Compliant to USB V2.0 for full-speed (12Mb/s)

Costs 5x the STM32. Now you can get even better MCU.

STOTG04E USB-OTG Full-speed Transceiver

Costs 10x the STM32. You can get the USB MCU and have a beer!

[ag123]

I think I may nevertheless play with a USB1T11A
https://www.onsemi.com/download/data-sheet/pdf/usb1t11a-d.pdf
as in part it is 'available in the online flea markets'

the attractiveness for 'bit banging' USB is in part as mcus like stm32g0xx series, which is quite 'modern' but lacks usb. They do have usb ones just in the 'higher end' part numbers with more sram and flash and comparatively pricier.

but that if one do not insist on g0 series and say use an 'older' series say the 'old' stm32fxx series, there are many with usb and for a little more than the g0. e.g. the stm32f103 series
then of course there is the 'feature packed' g4 series with usb and much more.

doing usb still wins over some 'crappy' usb-uart dongles as one has the whole usb protocol at your disposal, you can make 'any' device that fit in 'any' usb device class be they serial (CDC ACM), HID (keyboard and mouse), audio, ethernet, and practically thousands of 'usb' use cases ever defined. of course the easier way would be to get one with the usb hardware, only that currrenntly the 'lower' g0 series don't feature usb as part of it.

[DavidAlfa]

There's no attractiveness in bit banging USB, consuming 40% of the MCU resources, and spending the same (Or more)  in USB transceivers as a much better MCU.
It's like buying a 50hp Kia and spendign $5000 in engine mods, while you could have gotten a much better car to begin with.

[wek]

Or, use MAX3420E . It's even more expensive...

JW

[DavidAlfa]

For only $170 you can buy a 8GB rPI4, then communicate with it using spi 

[ag123]

Or, use MAX3420E . It's even more expensive...

JW

cool chip
MAX3420E
https://www.analog.com/en/products/max3420e.html
is a 'single chip usb engine', it is possibly feasible to take a stm32 with usb to emulate a similar interface. that said, another way is to simply use that stm32 
the hard part in usb is actually 'behind that transceiver' quite similar with wifi, bluetooth etc

i'm thinking there may be 'similar' offerings from FTDI one of the pioneers in such fields
https://www.ftdichip.com/old2020/Products/ICs/FT2232H.html

for the FTDI part, it is there in the 'online flea markets'
https://www.aliexpress.com/w/wholesale-ft2232.html
https://www.aliexpress.com/w/wholesale-ft232h.html
mostly cost more than a stm32 with usb, but that if it is a FTDI2232H - that one is high speed usb 480 Mbps, could be kept handy for some purposes.

oops even Adafruit feature such techniques, they are probably useful for niche apps
https://learn.adafruit.com/circuitpython-on-any-computer-with-ft232h/overiew

[ataradov]

1. SPI can only send an exact multiple number of bits, which is not the case in USB.
2. If you are doing USB FS, you have 4 clock cycles after the last bit is sent to prepare and set SE0. It is not happening.

And once again, sending is the easiest part. Forget about it for now. Think about receiving. How are you going to do that?

[ag123]

1. SPI can only send an exact multiple number of bits, which is not the case in USB.
2. If you are doing USB FS, you have 4 clock cycles after the last bit is sent to prepare and set SE0. It is not happening.

And once again, sending is the easiest part. Forget about it for now. Think about receiving. How are you going to do that?

It would most likely be an *experimental* project, there are things like clock recovery / sync which I did not think deeply enough about it. It is likely a difficult part.
https://www.engineersgarage.com/signal-and-encoding-of-usb-system-part-5-6/
https://gusbertianalog.com/clock-recovery-with-digital-pll/
^ this is probably too 'simplified'

one of another way is to oversample say at 48 Mhz, but that for stm32g0 it probably won't have enough prowess to do that, only possible in literal hardware.

for the 'general' reading, if the data can come in by SPI, it can simply populate a buffer, but that I'd need to search the buffer for the frame.
a benefit of using a transceiver as like USB1T11A
https://www.onsemi.com/download/data-sheet/pdf/usb1t11a-d.pdf
is that the data can stream in from a single pin, that makes it possible to read the bulk of that stream using SPI and DMA, hardware does it

Interrupts probably can't cope with 12 mhz speeds, but there may be situations it may be handy, at least to start the sampling etc.
stm32's timers may be an interesting tool to map certain scenarios
stm32s has quite a bit of hardware (peripherals) to try to attempt map those scenarios, but that there is no assurance that it is after all possible, but that if that 'software usb stack' is after all possible, then that stm32g0x0 probably have applications beyond its 'simple' self.
memory and flash constraint may be another challenge, they aren't very generous after all 8 k sram 32k flash, different part numbers has more flash and ram and the g031 series has a bit more vs the 'value' stm32g030 series.

the usb transceiver is probably 'overpriced' but that as hardware itself, it is probably much simpler than a microcontroller.
these days I stumbled into quite a few similar usb transceiver circuit being played as an IP core, i.e. to be included in chips rather than being chips themselves.

[Dan N]

I just finished a STM32G030 project using this bare bones proto board:
  https://github.com/dotcypress/placebo
  https://oshpark.com/shared_projects/tT7z3ldx

STM32G030 is perfect for small standalone applications that in the past would have been done on an 8 or 16-bit mcu.  I would have used STM32C0 except the G030 was a few cents cheaper.  Never would have thought of using this part if I needed usb.

If you do manage to get usb working I'd be interested to see it.

[ag123]

but well back on the topic  STM32G030 / G031 are probably useful in other apps - less that usb

[ataradov]

which I did not think deeply enough about it.

You should. Because once you do, you will realize it will not work and abandon this.

Even with 1.5 MHz, you only have 32 MCU clock cycles to handle a bit. And there is quite a bit of processing you need to do.

At 12 MHz you have 4 clock cycles and this is physically impossible to do.

one of another way is to oversample say at 48 Mhz, but that for stm32g0 it probably won't have enough prowess to do that, only possible in literal hardware.

This is not how software USB stacks are implemented.

for the 'general' reading, if the data can come in by SPI, it can simply populate a buffer, but that I'd need to search the buffer for the frame.

USB has strict timing requirements for the response, you will not have time to "search" anything. All processing must happen on the fly.

Forget about 12 MHz, it is not possible on this device.

[ag123]

it is kind of getting off-topic but that there are more 'ancient' chips - at least the specs floating around
Universal Serial Bus Full Speed Node Controller withEnhanced DMA Support Universal Serial Bus Full
https://www.ti.com/product/USBN9603
apparently 'obselete' and not featured

the main thing about the 'hard part' is that USB full speed SIE (serial interface engine) - that becomes a chip itself
apparently no longer stocked but that TI continues to sell the transceivers for those who would attempt to build the SIE
https://www.ti.com/product/TUSB2551A
https://www.ti.com/product/TUSB1106

these are quite similar to that USB1T11A
https://www.onsemi.com/download/data-sheet/pdf/usb1t11a-d.pdf

they did 'nothing much' except to make it 'more convenient' to handle the differential signals, and maybe its drivers/transistors can handle more current etc.


for SIE there are some like
MC9S08JM60
https://www.nxp.com/docs/en/application-note/AN3560.pdf
https://www.nxp.com/docs/en/data-sheet/MC9S08JM60.pdf
https://www.mouser.com/c/semiconductors/embedded-processors-controllers/microcontrollers-mcu/8-bit-microcontrollers-mcu/?processor%20series=MC9S08JM60
which are basically MCUs themselves and that they abstract that SIE + transceiver for the chips.

in that sense it would be about the same these days just getting a stm32 chip with usb
SIE is a 'hard part' to do in 'cheap' microcontrollers and those transceivers are kind of a tease 

[ataradov]

The reason all of this obsolete is that you can get < $1 MCU with a real USB peripheral.

If you want software USB, then plan for Low-Speed and direct connection to D+/D-. There is no scenario where adding one more IC that is not just an MCU with USB makes sense.

But even software USB on Cortex-M0+ is not easy and sort of pointless.

[DavidAlfa]

I purchased 100 STM32G030F6P6 for about 36€, and they all have the hidden flash and undocumented features (128MHz timer, 16bit hardware oversample ADC...).

Hey Potatobag, I just cheked the CubeMX xml files the STM32G041 also uses the same die (DIE466).
Have you tested if the AES / RNG / LPUART modules are functional?

(Then I found the die list in the Mikrocontroller.net thread was up to date).

DIE466  STM32G030C(6-8)Tx
DIE466  STM32G030F6Px
DIE466  STM32G030J6Mx
DIE466  STM32G030K(6-8)Tx
DIE466  STM32G031C(4-6-8)Tx
DIE466  STM32G031C(4-6-8)Ux
DIE466  STM32G031F(4-6-8)Px
DIE466  STM32G031G(4-6-8)Ux
DIE466  STM32G031J(4-6)Mx
DIE466  STM32G031K(4-6-8)Tx
DIE466  STM32G031K(4-6-8)Ux
DIE466  STM32G031Y8Yx
DIE466  STM32G041C(6-8)Tx
DIE466  STM32G041C(6-8)Ux
DIE466  STM32G041F(6-8)Px
DIE466  STM32G041G(6-8)Ux
DIE466  STM32G041J6Mx
DIE466  STM32G041K(6-8)Tx
DIE466  STM32G041K(6-8)Ux
DIE466  STM32G041Y8Y

I just ordered 20x G030s from Aliexpress, I hope they didn't clone them yet!

[DavidAlfa]

The chips arrived!
I bought these: https://www.aliexpress.com/item/1005005631825445.html
The measured current @ 64MHz was 5.6mA, very close to the datasheet specs, also the flash is really 64KB, so I'd say they're original.

To use all the peripherals simply choose the STM32G041F8P6 when creating the project.
However, to access the full 64KB flash a small modification is needed to bypass the programmer check.

Find the die used by your stm32 in the folder C:\ST\STM32CubeIDE_1.12.1\STM32CubeIDE\plugins\com.st.stm32cube.common.mx_xxxxxx\db\mcu.
For example, STM32G030F6Px.xml, it contains <Die>DIE466</Die>.

You can also make a full list of dies running this command in linux or cygwin, creating stm32_dies.txt (Source: Mikrocontroller.net).
I'm also attaching the extracted dies from CubeIDE 1.13.0.

Code: [Select]

cd (...fix this...)/STM32CubeIDE/plugins/com.st.stm32cube.common.mx_xxxxxx/db/mcu
grep -o "DIE..." STM* | sed -e "s/\(.*\).xml:\(DIE.*\)/\2  \1/" | sort >stm32_dies.txt

Now we have the first indication that our die has 64KB instead 32, as DIE466 is used both for the STM32G030F6P (32KB) and the STM32G031F8 (64KB):

DIE466  STM32G030F6Px
(...)
DIE466  STM32G031F(4-6-8)Px

So let's open the DIE466 XML file:
plugins\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_xxx\tools\Data_Base\STM32_Prog_DB_0x466.xml
Original:

      <!-- Embedded Flash -->
        <Peripheral>
          <Name>Embedded Flash</Name>
          ...
          <!-- 64 KB Single Bank -->
          <Configuration config="3,4,5">

Modified:

      <!-- Embedded Flash -->
        <Peripheral>
          <Name>Embedded Flash</Name>
          ...
          <!-- 64 KB Single Bank -->
          <Configuration config="0,1,2,3,4,5,6">

This also works for CubeProgrammer:
STM32CubeProgrammer\Data_Base\STM32_Prog_DB_0x466.xml
STM32CubeProgrammer\api\Data_Base\STM32_Prog_DB_0x466.xml


Test: The ST-Link still reports 32KB, but writes a 64KB program just fine.

ST-LINK SN  : -------------------------------
ST-LINK FW  : V2J41M27
Board       : --
Voltage     : 3.18V
SWD freq    : 4000 KHz
Connect mode: Under Reset
Reset mode  : Hardware reset
Device ID   : 0x466
Revision ID : Rev 1.1
Device name : STM32G03x/STM32G04x
Flash size  : 32 KBytes
Device type : MCU
Device CPU  : Cortex-M0+
BL Version  : 0x53

Memory Programming ...
Opening and parsing file: ST-LINK_GDB_server_a14288.srec
  File          : ST-LINK_GDB_server_a14288.srec
  Size          : 63.91 KB
  Address       : 0x08000000

Erasing memory corresponding to segment 0:
Download in Progress:
File download complete
Time elapsed during download operation: 00:00:01.118
Verifying ...
Download verified successfully

The RNG works, all registers can be accessed/modified, and DR reg generates random numbers all the time.

However the AES registers are always read 0, nor can be modified, so probably it's permanently disabled at die level (Of course, RCC peripheral clock was enabled).

ST has never blocked the flash before, so it woudl be rare that hey started now. Lots of 32, 64, 256 and even 512KB devices have double the flash!
Doing this for large-scale production would be risky, as you never know if the the second flash block could be defective somehow, not inmediately failing on programming verification.

China products have been doing this for ages with the STM32F101, although reduced SRAM, still has fully working 128KB and USB from the STM32F103.

[tszaboo]

I just finished a STM32G030 project using this bare bones proto board:
  https://github.com/dotcypress/placebo
  https://oshpark.com/shared_projects/tT7z3ldx

STM32G030 is perfect for small standalone applications that in the past would have been done on an 8 or 16-bit mcu.  I would have used STM32C0 except the G030 was a few cents cheaper.  Never would have thought of using this part if I needed usb.

If you do manage to get usb working I'd be interested to see it.

It's an excellent chip IMHO. I used it for a model train DCC decoder, not only does it use much less current than the usually used Atmega328, it's a lot cheaper, smaller and faster. And compared to the STM32F0 it wastes much less pins on VCCs and Boots. It doesn't have USB but not everything needs to connect to a PC.

[Sacodepatatas]

Hey Potatobag, I just cheked the CubeMX xml files the STM32G041 also uses the same die (DIE466).
Have you tested if the AES / RNG / LPUART modules are functional?

Oooppss, i've been busy and seems that i read you late. I could modify the I2S interface in my firmware for testing if i can output white noise generated by the RNG, but i don't know if the RNG speed would be enought for 2x16bit@44.1ksps. I've taken a look to the STM32G0x0 RM and i found that some members of the family can setup the RNG clock throught a prescaler. However i didn't find if the G041's RNG speed can be changed or maximized.

EDIT: Acording to a thread from stm32duino forum, the LPUART also works on the G030 (and the TRNG confirmed it is the same one as in the G041).

EDIT2: I found very useful links:

https://dannyelectronics.wordpress.com/2023/08/23/are-stm32g030-031-really-the-same-as-stm32g041/
https://dannyelectronics.wordpress.com/2023/08/23/is-stm32g030-really-a-stm32g031/

[DavidAlfa]

The TRNG works up to 48MHz and produces new numbers as follows:

It produces four 32-bit random samples every 16x(fAHB/fRNG) clock cycles, if value is higher than 213 cycles (213 cycles otherwise).
...
Four new words are added to the conditioning output register 213 AHB clock cycles later

At 64MHz AHB and 48MHz RNG: 16*(64/48) = 21, so it's 213 cycles anyway.
64MHz/213 = 300K. But this is 300K * 4 32-bit numbers, so 1.2M 32-bit numbers

You have several clock sources (SysClk, PLLQ or HSI/8) and a final prescaler ( 1:2:4:8 ).
With some tweaking, you can get PLLQ to 96MHz, dividing it by 2 to get 48MHz, but running the TRNG fast seems to not be useful, as it's ultimately limited to 213 AHB cycles.

At fAHB=64MHZ and fRNG=SysClk/8=8MHz, the relation is 128 clocks, so it'll wait those 213 AHB cycles anyways.

Nice links! 

[Sacodepatatas]

Oooppsss!! I don't get how could I miss that part in the RM 🤦🏻‍♂️. Thank you so much for such detailed explanation.

[DavidAlfa]

No idea if the chips are counterfeit, or if it's a library, IDE or debugger bug.
When debugging virgin chips I was having strange issues when any IRQ triggered, getting the PC into weird memory areas and crashing.

Checking VTOR reg, it cointained a weird value like 0x3ffff000. What?

In SystemInit(), VTOR was left at default reset value (USER_VECT_TAB_ADDRESS is not defined by default):

Code: (/Core/Src/system_stm32g0xx.c) [Select]

void SystemInit(void)
{
  /* Configure the Vector Table location -------------------------------------*/
#if defined(USER_VECT_TAB_ADDRESS)
  SCB->VTOR = VECT_TAB_BASE_ADDRESS | VECT_TAB_OFFSET; /* Vector Table Relocation */
#endif /* USER_VECT_TAB_ADDRESS */
}

From the CM0+ manual, this should be OK:

On system reset, the vector table is fixed at address 0x00000000.

But I suspect the debugger had something to do with it. Or STM32BuggedIDE.
Just in case I added USER_VECT_TAB_ADDRESS to the preprocessor, so the section was enabled, effectively resetting VTOR to the default value, 0:

Code: [Select]

#define VECT_TAB_BASE_ADDRESS   FLASH_BASE      /*!< Vector Table base address field.
                                                     This value must be a multiple of 0x200. */
#define VECT_TAB_OFFSET         0x00000000U     /*!< Vector Table base offset field.

Still, I had strange bugs several times when using the debugger reset button, again getting PC into 0x1FFFxxxx. Like it didn't reset something properly.
Had to close the ide, wipe Debug and Release folders, make new builds, only then it stopped the mess.

ST magic! But I'll leave the VTOR code enabled anyways, it's just few instructions.
Knowing ST, trust nothing. Everything that should be, will not in the Errata sheet .