Comment by dmitrygr | Hacker News Reader

Comment by dmitrygr | Hacker News Reader

Parent Full thread

Be veeeery careful. STM32H QSPI peripheral is FULL OF very nasty bugs, especially the second version (supports writes) that you find in STM32H0B chips . You are currently avoiding them by having QSPI mapped as device memory, but the minute you attempt to use it with cache or run code from it, or (god help you) put your stack, heap, and/or vector table on a QSPI device, you are in for a world of poorly-debuggable 1:1,000,000 failures. STM knows but refuses to publicly acknowledge, even if they privately admit some other customers have "hit similar issues". Issues I've found, demonstrated to them, and wrote reliable replications of:

* non-4-byte-sized writes randomly lost about 1/million writes if QSPI is writeable and not cached

* non-4-byte-sized writes randomly rounded up in size to 2 or 4 bytes with garbage, overwriting nearby data about 1/million writes if QSPI is writeable and cached

* when PC, SP, and VTOR all point to QSPI memory, any interrupt has about a 1/million chance of reading garbage instead of the proper vector from the vector table if it interrupts a LDM/STM instruction targeting the QSPI memory and it is cached and misses the cache

Some of these have workarounds that I found (contact me). I am refusing to disclose them to STM until they acknowledge the bugs publicly.

I recommend NOT using STM32H7 chips in any product where you want QSPI memory to work properly.

What the hell is going on at ST? Every STM uC I've tried to use in the past few years has had showstopper bugs with loads of very similar complaints online dating back to the release of the part. Bugs that have been in the wild for years and still exist in the current production run.

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.

In college, our SoC design instructor told us that to pass the class, our modules should be better than ST's "which is not that high of a bar" :P

It seems endemic with embedded devices. Only big customers get the true list of errata, and of course the errata are random PDFs rather than a useful format. Even just having them on an ftp site with all the errata in one spot would save so much pain!

Sometimes you don't even get a PDF. Their Ethernet drivers for Cortex-M7 have been broken for years with subtle cache coherency bugs and the only discussion of it is a forum thread with now obsolete example code.

Oh no! I luckily never dealt with the ethernet drivers, but I had plenty of small issues with other drivers

They churn out new parts and don't bring in fixes. See all the chips in their lineup that have a USB host controller. Every one of them (they use Synopsys IP) will fail with multiple LS devices through a hub. We talked to our FAE about this and they have no plans to fix it. The bug has existed for years and the bad IP is being baked into all the new chips still. Solution? Just use yet another chip for its host controller, and don't use a hub.

Have you tried PSoC parts? How does that stack with other microcontrollers?

Thanks for the heads up. I have a design at fab that uses the H7's OctoSPI so this concerns me. I steered away from the memory mapped mode because it seemed too good to be true - wanted to be able to qsort() and put heaps in this extra space.

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.

it is worse: i think they also did not test random access. I suspect their test was to: fill PSRAM linearly and then read it back and verify linearly. Random word accesses in unachached mode also randomly lose writes. I am unable to replicate quickly on purpose, only randomly, so i guess it is under 1/100mil so it is not in my list above. My workarounds avoid these crashes too though.

I have encountered issues with QSPI (mostly caused by the annoying prefetch queue) which is why I am switching to the FMC for FPGA interfacing (i.e. not using OCTOSPI). That was the whole point of this experiment, validating FMC as a replacement for my legacy OCTOSPI based MCU-APB bridge. I have a previous board using QSPI reliably in indirect mode (i.e. not memory mapped) but found it was full of pain when memory mapped specifically in writes. So that firmware memory maps it for reads but switches to indirect mode for writes. And has cache disabled.

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 NXP IMXRT-series chips have a similar EMC (external memory controller) as well as "FlexIO" - PIO-like programmable IO. I've used both for this kind of FPGA interface 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.

I have some RT1176's in my "to try" pile.

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.

> I have some RT1176's in my "to try" pile.

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.

> 100K reads/writes of a 32-bit register

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

Yeah but again, we're talking about the FMC here not the OCTOSPI.

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.

lol, I'm working on an FMC-FPGA interface at work right now and discovered this same chipselect behavior.

It's a documented errata, 2.6.1 on page 8 of ES0491.

As far as using QSPI memory, one thing I have planned (and will be thoroughly testing) is using an external SPI flash as configuration data storage. Right now if I want to store any nonvolatile settings with power loss protection I need to burn two 128 kB erase blocks (one primary and one secondary, so I can ping-pong data between them and not lose anything if I have a power loss during a write cycle or similar) of the on-chip flash, space that I'd much rather use for firmware.

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

But if I can memory map the FPGA via the FMC, I can simply put an APB memory mapped QSPI controller on the FPGA and store my config there, using the same flash for the FPGA bitstream as well.

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.

I almost always include I2C EEPROM - just too cheap and pretty easy to route.

That can't be memory mapped, so I'd need to rewrite my KVS code which currently expects to be able to return a pointer to the raw on-flash image of the config data. Doable but a pain.

Reply on news.ycombinator.com