Starting to look more seriously into the STM32H750/753.
The 753 is the part I really want to use, the 750 is the same die fused down to disable all but the first 128 kB of flash. But I picked up several of them during the chip shorage and I feel like I should put them to use.
They're mostly comparable to the H735 I use now. Key differences:
* CPU Fmax down from 550 to 480 MHz
* RAM nearly doubled from 564 to 1024 kB
* Flash increased from 1 MB to 2 MB in the 753, but reduced to 128 kB in the 750
* 40 more GPIOs (128 -> 168)
* Package enlarged from 201 ball 0.65mm (10x10 mm) to 265 ball 0.8mm (14x14 mm).
That last bit is what has me the most interested. The 0.65mm H735 package is usable on OSHPark 4L, barely, but you lose a lot of IO and the parallel memory controller etc. aren't practical to use.
While the H75x is available in the same footprint, you can also get it in the 0.8mm package which should be much more friendly to the large via sizes offered on OSHPark. So it could be a winner for prototypes where I care more about ease of access to IO and MCU-FPGA interfacing than about absolute max CPU performance.
Andrew Zonenberg
in reply to Andrew Zonenberg • • •The limited flash on the H750 should mostly be a non issue. My typical firmwares so far are barely over 128 kB all told, and I have a ton of executable RAM to work with.
So I can put a minimal bootloader and BSP (and maybe firmware update SFTP server) in the internal flash, bring up the FPGA, then copy my application image from spare space on the FPGA config flash to SRAM and jump to it.
The only other issue is that I normally run microkvs in the last few flash sectors. So in a single-sector flash part, I can't do that. Instead, I'd need to add a memory mapped interface to the FPGA-attached flash and store my config there. (I could also attach an extra QSPI flash to the MCU but that adds BOM cost, it's more pins to route, and most importantly involves dealing with the cursed OCTOSPI peripheral).
It'd take a bit of coding to get all of this done, but I think it's worth the effort. I may still go with the 753 for new designs long term but since I have 750s on the shelf, might as well use them up for one-off / low volume projects.
The larger BGA ball pitch alone is enough of a reason.
ティージェーグレェ
in reply to Andrew Zonenberg • • •"firmware update SFTP server"
Wow! Please continue to create a future that will hopefully help me forget the bygone era (I hope) of updating device firmware via XMODEM/CRC (I suppose I should at least be thankful that creator chose an XMODEM variant with a CRC!) or TFTP.
Though I wonder, (looking locally at some aarch64 ssh daemons):
-rwxr-xr-x 1 root wheel 476488 May 31 22:04 /opt/local/sbin/sshd*
-rwxr-xr-x 1 root wheel 764272 May 4 05:39 /usr/sbin/sshd*
I guess SFTP support might eat up a lot of that constrained flash space?
Chuck
in reply to Andrew Zonenberg • • •Ben
in reply to Andrew Zonenberg • • •I've been using the H757 dual core in the .8mm 256 BGA. I'm pretty happy with it.
It takes a bit to get used to debugging, you flash it using the M7 which does memory for both cores, but if you want to debug the M4 you have to connect without downloading anything.
The biggest pain so far is M4 can't read some sysmem stuff - like ADC calibration values. I use a shared memory struct to pass data between cores.
I use the M4 to handle ADC, UART, etc, and M7 to draw the MIPI display.