After burning enough company time chasing bugs through ST's crappy silicon, I've had to just swear them off entirely. We're an Atmel house now. Significantly fewer (zero) problems, and some pretty nifty features like UPDI.

So far I have it working quite reliably (my test firmware does a loopback test with 100K reads/writes of a 32-bit register at the start that I had written with intent of using it for link training of the PLLs to optimize read/write capture timing but never ended up using as such) and my iperf test can push tens of thousands of packets per second without issue.

The IMXRT1064 is around $7 and is also an M7 core with an HS USB PHY, programmable PLL-connected LVDS clock output, 2 EMACs, excellent hardened IP generally.

The big thing holding me back was that their crypto accelerators were all locked behind NDAs (a dealbreaker for F/OSS work) while the ST ones are documented in the freely downloadable datasheet you can just google up.

But I did find some third party wrapper libraries that seemed to be able to use the crypto registers so it might be possible to figure things out from that. I haven't tried yet.

The other issue I had with the RT is that they lacked internal flash so PCB complexity is slightly higher than with a STM32.

Keep in mind the dual-core 11xx chips are a bit harder to boot than the rest of the line - but you probably need the power domain flexibility for most FPGA projects (1064 has way fewer practically-usable 1v8 banks.)

> crypto accelerators were all locked behind NDAs

I've been able to use every bit of hard IP and high-assurance boot from registers using no vendor code whatsoever.

Here's what you are looking for:

https://github.com/JayHeng/imxrt-level2-boot/blob/master/dev...

> The other issue I had with the RT is that they lacked internal flash

The IMXRT1064 has a 4MB Winbond QSPI chip in-package, by the way!

> PCB complexity is slightly higher than with a STM32.

The Xilinx FPGA that is sitting next to your MCU incurs multiple orders of magnitude more PCB-complexity than a little QSPI flash, haha.

You'll hit almost no bugs if you keep accessing the same address in a loop. Lucky you :)

Have you hit issues with the FMC? From what other people are telling me, the OCTOSPI is full of land mines and the FMC is pretty decent. The worst errata I've encountered so far is two dummy clocks with CS# asserted at the end of a read burst.

I suspect ST only ever tested it with their single PSRAM they intend this mode for. My intent is to use indirect mode and manually poke the peripheral, though DMA will have to happen still.

Back on the PIC32MX platform there was a similar type of bug that doesn't exist anywhere else but to me: If any interrupt fires while the PMP peripheral is doing a DMA, there is a 1 in a million chance that it will silently drop 1 byte. Noticed this because all my accesses were 32bit (4 bytes) and broke horribly at the misalignment. The solution is to disable all interupts while doing DMA.

MicroKVS expects to be able to memory map data fetches (uncached), but is fine with using indirect access for writes.

This saves a chip on the board, reduces the amount of PCB routing required, and eliminates use of the sketchy OCTOSPI peripheral entirely. Testing that out is on my list of things to do on this board eventually.