Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Memory Mapping an FPGA from an STM32

serd.es

Post reply on HN
Print view View original

21–30 of 66 posts

Re: Memory Mapping an FPGA from an STM32

#21

Post by azonenberg »

duskwuff wrote: post #18
azonenberg wrote: post #9

Earlier quoted context omitted.

H735 is one of the single core SKUs. Just a 550 MHz M7. Would not surprise me if the M4 was there and fused off (i.e. same die as multicore H7 offerings), but it's not active.

Probably not. The dual-core parts are DIE450 (which is shared with some single-core parts like the H750 series!), but STM32H735 is DIE483.

I have a H735 on a retired board slated for decap so we'll find out once I open it up.

Do you know if it's fabbed in house, TSMC, or Samsung? I've seen ST silicon from all 3 foundries but the only thing I've seen stated publicly is 40nm. When I get it opened up it should be easy to tell, TSMC and Samsung processes have distinctive features on them that I recognize by sight.

Re: Memory Mapping an FPGA from an STM32

#22

Post by mips_r4300i »

dmitrygr wrote: post #19

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,…

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.

Re: Memory Mapping an FPGA from an STM32

#23

Post by azonenberg »

dmitrygr wrote: post #19

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,…

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.

Re: Memory Mapping an FPGA from an STM32

#24

Post by 15155 »

azonenberg wrote: post #20
dmitrygr wrote: post #19

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,…

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 ma…

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.

Re: Memory Mapping an FPGA from an STM32

#25

Post by mystified5016 »

dmitrygr wrote: post #19

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,…

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.

Re: Memory Mapping an FPGA from an STM32

#26

Post by azonenberg »

15155 wrote: post #24
azonenberg wrote: post #20

Earlier quoted context omitted.

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 ma…

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.

Re: Memory Mapping an FPGA from an STM32

#27

Post by 15155 »

UncleOxidant wrote: post #3
Already__Taken wrote: post #2

real quite high level sorry, most of your embedded projects going forward are MCU+fpga to do what? I thought a custom router but 284mbps isn't nearly fast for a network.

It's a good question. A lot of FPGA projects I see (including some real life products I've looked into recently) don't really need an FPGA. One I was asked to evaluate recently could easily have been done with a microcontroller with PWM outputs. The frequencies involved were well under 40MHz. Yes, there were a couple of multiplications going on in the FPGA, but there those could've been easily handled by a micorcontr…

Zynq 7010s are $2.50 and are a hell of a lot more chip than an RP2040. If you already have the design (or copy one of the 50 available), it's a good option when you don't want to fight the chip.

PIO has extraordinarily sloppy timing (skew in all categories) compared to the cheapest and smallest FPGAs.

Re: Memory Mapping an FPGA from an STM32

#28

Post by azonenberg »

azonenberg wrote: post #23
dmitrygr wrote: post #19

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,…

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 t…

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.

Re: Memory Mapping an FPGA from an STM32

#29

Post by dragontamer »

Already__Taken wrote: post #2

real quite high level sorry, most of your embedded projects going forward are MCU+fpga to do what? I thought a custom router but 284mbps isn't nearly fast for a network.

Embedded projects are never about doing things as fast as computers: we have full scale computers (and routers, and firewalls, and switches) for that.

Embedded is about solving problems more physical in nature, as you are physically closer to reality in nearly all aspects.

--------

An MCU + FPGA project could implement... say... the VFIR IrDA (Infrared) protocol at 16Mbit.

Traditional IrDA is widely supported at SIR and MIR levels (upto 1.152MBit or so). Anything faster and the equipment has basically been lost to the 1990s (and never was very popular anyway).

IrDA I'd explain as a remote-controller on steroids. Its infrared based (like TV Remote Controllers), so you need to line up both devices and have them looking at each other. Infrared can reliably travel about 3 meters over the open air in a variety of conditions. IrDA allows for bidirectional communications. Its a truly wireless protocol, albeit one that requires significant alignment to function correctly. But ~3 meters is good range and practical for many applications.

Nominally, you could use an entire MCU to handle the encoding / decoding of these light-pulses. However, that's a bit redundant. Its far more cost efficient to dedicate a few LUTs in an FPGA to the task.

Yes, the MCU is needed for the final application-level / OSI layer 4/5/6/7 aspects of IrDA protocol. But the lowest PHY and MAC levels of the protocol can and (probably) should be a small section of FPGA.

Upgrading from standard MCU 1MBit to 16MBit would be a 1600% improvement to communications compared to what's readily available with commercial-off-the-shelf solutions. If you've determined that IR Communications is good for whatever purpose you're using, maybe the 1600% improvement is going to be useful.

------------

EDIT: The "physicality" of this is because photodiodes react very quickly to light pulses. And an expensive enough transistor can amplify that at the ~100MHz speeds needed to run VFIR (at least in theory. I've never done this).

The FPGA (or MCU if you go that route...) just needs to clock at 100MHz or so, and interpret the start-of-frame and end-of-frame signals, while also interpreting a few other low-level details. Overall, this turns the sequence of light pulses into bits-and-bytes for higher-level processing (which code can and should handle).

Re: Memory Mapping an FPGA from an STM32

#30

Post by 15155 »

azonenberg wrote: post #26
15155 wrote: post #24

Earlier quoted context omitted.

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 h…

> 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.

Post reply on HN