STM32G030 / G031

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