The chip shortage has led to some complications, and I've built a batch of products using any chips I can lay my hands on. This has led to a random selection of STM32s: the F042F6P6, F042F6P7, and F070F6P6. They're mostly compatible, but my application uses USB, so ...
- Best practice for F042 is to use HSI48 and the CRS to generate a decent USB clock.
- Only alternative for F070 is to use PLL multiplied up, but that's OK because the F070 has a tighter clock tolerance.
In practice, using the PLL for everything seems fine but I've got hundreds of these around the world based on F042s already, so it makes me uneasy that the next firmware update might be messing with something that already works.
Trying to use the HSI48 on the STM32F070 silently breaks the USB as you'd expect: the rest of the chip functions normally; peripheral initialisation works; one gets the RESET interrupt when the host tries to talk, but no data ever gets through.
So how can we automatically tell the difference between the chips to select the correct mode? DEBUGMCU_IDCODE comes back with 0x445 rev 0x1000 for both chips; HSI48RDY flag works on both chips; the CRS peripheral seems to function and reset as normal on both chips. Even though neither is a documented feature of the F070.
As far as I can tell, F070 is basically identical to F042 but the CAN peripheral has been exposed and the link between HSI48 and USB has been removed. I spent all day on this and eventually made it an option byte, but that's an extra and easily-overlooked step in production commissioning.
