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

Debugging bare-metal STM32 from the seventh level of hell

jpieper.com

Post reply on HN
Print view View original

61–70 of 70 posts

Re: Debugging bare-metal STM32 from the seventh level of hell

#61

Post by HeyLaughingBoy »

dmitrygr wrote: post #13
jhallenworld wrote: post #11

Earlier quoted context omitted.

But balanced against basically unlimited flash size. Many of my projects end up having an external SPI-flash for one reason or another anyway. Another similar chip is the i.MX rt1020 from NXP (except Cortex-M7 and way more expensive). The one gotcha was that there was only one QSPI-flash controller even though there were two ports. It meant that the extra port (which we assumed would be available during architecture)…

> Many of my projects end up having an external SPI-flash for one reason or another anyway. for what? What sort of possible thing would you need to do on a c-m0 that needs more than 128K of CODE!?

The libraries you pull in can be big. Add, e.g., LWIP for internet, USB filesystem management (data logging and USB firmware update), code to properly manage OTA or Ethernet updates, text strings, especially in multiple languages, etc.

What seems like a huge amount of Flash disappears quickly.

Re: Debugging bare-metal STM32 from the seventh level of hell

#62

Post by HeyLaughingBoy »

vardump wrote: post #17

This is really just how low-level embedded land is like. Hardware is often buggy.

Thankfully it's usually not this bad. I remember spending a lot of time debugging a problem because although the signs pointed to bad hardware, it was in such a commonly-used feature that I knew it had to be my code. Otherwise, everyone else who used the part would be screaming at the manufacturer.

After I finally admitted defeat and called my TI (Texas Instruments) support engineer, he said, "oh, that's a brand new part. You guys are actually only the second company we've sold it to. Thanks for the bug report, but we just discovered it last week so it'll be fixed in the next rev."

Re: Debugging bare-metal STM32 from the seventh level of hell

#63

Post by jpieper »

the__alchemist wrote: post #58
dognotdog wrote: post #47

Earlier quoted context omitted.

I just bought 10 off digikey last week, to have some prototyping stock. Looks like they still got some: https://www.digikey.com/en/products/detail/stmicroelectronic... Octopart, etc haven't been able to accurately track inventory through this disruption.

Good to know! I've been trying to get hold of certain H7 and G4 variants in a specific footprint. Family and footprint are a hard requirement, but not too picky otherwise. Checking it out. Of note regarding the one you linked - great find; looks like that Octopart link was bad! I actually have some 491s, and they're great, except that the OSS firmware I'm using them with for this project doesn't support them. Got my…

I'm curious what other OSS firmware is using the G4 series?

Re: Debugging bare-metal STM32 from the seventh level of hell

#64

Post by dmitrygr »

kragen wrote: post #23
dmitrygr wrote: post #13

Earlier quoted context omitted.

> Many of my projects end up having an external SPI-flash for one reason or another anyway. for what? What sort of possible thing would you need to do on a c-m0 that needs more than 128K of CODE!?

Wait, wasn't there some guy who got an entire Linux system booting on a microcontroller that's smaller than a Cortex-M0? https://dmitry.gr/?r=05.Projects&proj=07.%20Linux%20on%208bi...

Yup, I did. that’s why I ask

Re: Debugging bare-metal STM32 from the seventh level of hell

#65

Post by markrages »

dave78 wrote: post #52
frmdstryr wrote: post #44

Earlier quoted context omitted.

> always avoided interrupts I'm curious... how does one achieve precise timing without interrupts?

Cycle counting is common. Other options exist like a tight loop watching a counter register etc.

Cycle counting is dead for ARM chips with their wait states and instruction pipelines and lazy stacking. Works great for PICs though.

Re: Debugging bare-metal STM32 from the seventh level of hell

#66

Post by dmitrygr »

jhallenworld wrote: post #14
dmitrygr wrote: post #13

Earlier quoted context omitted.

> Many of my projects end up having an external SPI-flash for one reason or another anyway. for what? What sort of possible thing would you need to do on a c-m0 that needs more than 128K of CODE!?

Not so much for code, but lots of use for persistent data (logs, databases, etc.). Only a part of it would be used for XIP. Also with more flash space it's easy to have multiple banks for safe firmware update and the like.

> logs, databases

in NOR flash???

:cringe:

Re: Debugging bare-metal STM32 from the seventh level of hell

#67

Post by civilitty »

pabs3 wrote: post #16
realcertify wrote: post #3

Earlier quoted context omitted.

There's plenty of STM32 of any flavor in China. Alibaba is a good source. There may be fakes though, but reputable resellers (pay attention to reviews and tenure) normally sell genuine chips.

Are fakes of lesser quality? How do you tell fake from genuine?

You have to research the counterfeit market for each chip/product series. There's no hard and fast rule for their quality because many of them come from the same factories that make the real chips when unscrupulous fabs have shadow shifts manufacturing their clients' designs for themselves or just straight up copy and rebrand it.

Re: Debugging bare-metal STM32 from the seventh level of hell

#68

Post by the__alchemist »

jpieper wrote: post #63
the__alchemist wrote: post #58

Earlier quoted context omitted.

Good to know! I've been trying to get hold of certain H7 and G4 variants in a specific footprint. Family and footprint are a hard requirement, but not too picky otherwise. Checking it out. Of note regarding the one you linked - great find; looks like that Octopart link was bad! I actually have some 491s, and they're great, except that the OSS firmware I'm using them with for this project doesn't support them. Got my…

I'm curious what other OSS firmware is using the G4 series?

Betaflight

I also have custom flight controller firmware in Rust that's running fine on G491, but Betaflight needs 47x or 48x.

No luck on getting H7s.

Re: Debugging bare-metal STM32 from the seventh level of hell

#69

Post by glonq »

varispeed wrote: post #20

How did they manage to get STM32s? My friend's small business had to close, because key MCU is not available anywhere and Chinese sell it for the price of the end product. Makes business no longer viable. He spent over a month designing board for another MCU that was available at the time, but as soon as he was ready to produce more the alternative was gone too. It's like chasing own tail. Big corporations can post h…

I hope your friend's other MCU wasn't GigaDevices, because we are currently switching two products over from STM32 to that!

Re: Debugging bare-metal STM32 from the seventh level of hell

#70

Post by jhallenworld »

dmitrygr wrote: post #66
jhallenworld wrote: post #14

Earlier quoted context omitted.

Not so much for code, but lots of use for persistent data (logs, databases, etc.). Only a part of it would be used for XIP. Also with more flash space it's easy to have multiple banks for safe firmware update and the like.

> logs, databases in NOR flash??? :cringe:

NOR is more durable than NAND (but smaller, more expensive per bit), but yes you have to be careful with logs. In most recent case, it was in the 10s of small records per day.
Post reply on HN