STM32U5xx: thank you for a really "cool" MCU

[tjaekel]

Dear STM32 team,
I want to thank you, honestly, for a really great MCU chip. Well done.
(just as my friendly feedback to you and company)

When I say, the STM32U5xx is a really "cool" MCU - I mean two things:

• It is really cool, in terms of temperature:
  I am impressed: my board (with few external components, like LDOs, LED, OSC) draws just 20mA (in full-speed mode) - very impressive.
• And the die temperature remains almost with ambient temperature, 29C (in a 20C room) - very impressive.

But "cool" means also to me having some nice features:

• I like the OCTALSPI: very nice to have now a free user QuadSPI interface:
  just: it would be nice to use OCTALSPI also as a regular "full-duplex" SPI interface, like any other SPI,
  in single-SPI mode (it is still a half-duplex SPI interface, instead, not a full-duplex as any other "regular" SPI)
• I like the memory size, esp. in a STM32U5A5 chip (huge flash memory, huge SRAM, even better as a STM32H7xx MCU, "cool")
• I like the new and additional features like CORDIC and FMAC: very helpful, esp. for HW-oriented real-time programmers (like me).
• "cool" that some GPIOs (PG2..15) have now a separate VDDIO2 going down to 1.08V - pretty "cool"
  (unfortunately, just in specific and larger packages - I wish to have this option on all packages)
  it would be "cool" to have also a separate VDDIO, on all packages, for all pins:
  I need often 1V8 and even 1V2 logic signals, meanwhile. To have OCTALSPI, SPI, I2C ... as 1V2 logic, even core MCU (and USB) runs at 3V3 - would be "cool".
• The most I like: the integrated, internal USB HS PHY. Well done!
  

One SW question:

This STM32Uxx MCU does not provide anything for ETH (no ETH support, no ETH PHY RMI interface). But fine
and obvious for a real low-power MCU.

Would it be possible, if you could provide an USB based example for "ETH-over-USB"?:

• a demo project/application where USB is used (together with RNDIS host drivers)
• to use USB as network/TCP/IP access to MCU

I want to connect this MCU like a network device, via USB, e.g. to run TFTP in order to transfer data or TCP/IP as communication interface from host scripts.
Why?
Often, in companies, the use of USB Memory Devices is prohibited. So, if I want to transfer files to/from MCU, even using the ST-LINK with the USB Memory option enabled, using MCU as memory device ... is not legal and not allowed - an USB based network access would be "super cool".

I like all your STM32 MCU, I am a big fan of STM32 (esp. H7, now also U5).
And your MCU is so "cool" that I would come back from an NXP RT1170 MCU - because the features I need (like QSPI as a user interface) were not yet available on STM32 before. But now it does. Well done!
(I went with NXP RT1170 because of their FLEXIO feature - should you consider a similar approach?)

Other "cool" features which I might miss (as potential new features in your future MCUs):

• The DLYB is just usable for SDMMC or OCTALSPI:
  Why not having also DLYB as feature on regular SPI (in order to compensate a "round trip delay" via SPI)
• The "parallel synchronous interface" (PSSI) is just a slave:
  It would be "cool" to have it also as a master option, so that I can connect two MCUs with it.
• it would be nice, in addition to the ALT pin multiplexer, to use an output pin, generated by a device (e.g. OCTALSPI_NSS), to use also as an input on another device (w/o external wiring) (e.g. as SPI1_NSS)
• Realign some pins so that a similar function is possible, e.g.:
  OCTALSPI_IO1 could be aligned with a SPI MISO signal, etc., so that I can toggle between QSPI and regular SPI, but all signals still on the same pins (right now they are not sharing the same pins).

Anyway: Thank you for a new great MCU.

[STOne-32]

Dear @tjaekel ,

Great to see your testimony and The  « cool » experience with our STM32U5A MCU. Thank you gain for the ideas and feedbacks , We will escalate to our R&D teams, they will appreciate for sure !

Have a great weekend 

STOne-32

[David Littell]

Yeah, sorta mostly, except...

- The maximum core clock rate is too slow, data caches are too small, and D-TCM's should be included in all family members.

- From a software perspective, the STM approach to DMA is far too complicumbersomevoluted.  (This is true in all STM32 devices.)  The designers could take some good lessons from the old Motorola MC68450 DMA chip (and documentation!) and realize that complication != sophistication.

- The documentation needs to rewritten by native English speakers.  Some sections of the Reference Manual are downright unreadable.

[STOne-32]

Hi @David Littell ,

Thank you very much for the valuable feedback ! Much appreciated, I will give to our R&D teams including documentation, if possible to be a bit specific And I would very grateful if you could point to the page or section in the Reference Manual as example to show . Thanks again ! 

Cheers,

STOne-32

[David Littell]

RM0456 Section 17 is a particularly difficult swim, especially the linked-list stuff.  Somebody loves commas in sentence structures that are often far too complex - Koine Greek this is not supposed to be.

[Uwe Bonnes]

Better consider a SPI connected ETH interface.

[tjaekel]

I have: Portenta H7, NUCLEO-H743ZI2/NUCLEO-H745ZI-Q, NXP1170 (Maaxboard-RT)...
All fine. I went with STM32U5xx mainly because of QSPI supported (SPI via ETH - I have working since years).
Question about ETH was not to add ETH to STM32U5xx (keep it low power!) - just: if possible to use USB (and RNDIS host driver) for network (not very important, just to reuse existing host scripts via network also for this MCU).

To David:

160 MHz for a low-power MCU is good and impressive (esp. when I see high small the current and heat dissipation is). For faster speeds - there are F7 and H7.

DCACHE on this MCU is anyway just for external memory: internally we do not need DCACHE (the RAM runs at the same speed).

The same for DTCM: not needed: RAM runs with same core clock speed (DTCM would not make sense).

DMA: it could be a bit challenging to configure a DMA. But the DMA in chip is very flexible, e.g. MEM-to-Periph., with linked lists for several transfers, increment address or not (e.g. when a FIFO is connected vs. memory range)... Not any concern for me.
BTW: I have used (on other MCUs, projects) also the DMA2D (intended for graphic DMA) for regular memory transfer: once I had a need for a "vector DMA" (not linear address space) and it was working (and the DMA2D is even more "complicated").