Debugging bare-metal STM32 from the seventh level of hell

Post by jhallenworld » Mon, Aug 08, 2022, 6:23 AM UTC

dmitrygr wrote: post #10

jhallenworld wrote: post #5

Earlier quoted context omitted.

If you can use Cortex-M0+ (so not likely for this project, BLDC where you want floating point), maybe think about RP2040 (Raspberry Pi Pico chip)? More than 100K of them in stock at Digikey, only $1 each... But they come in only one package type, and use external flash (an advantage, IMHO). I've recently started looking at them. The SDK is nice except that they chose to use CMake. I designed it out: https://github.co…

> an advantage, IMHO it isn't An extra chip means higher cost to produce & assemble board, larger board size, more pins wasted on this nonsense, most fast-edge signals to route, more passives, extra risk to handle for one extra chip being out of stock, and it is much easier to extract firmware than even from a "protected" stm32 Also wasting RAM (and power for it) on code, or random (between high and very high) latenc…

Post by dmitrygr » Mon, Aug 08, 2022, 6:29 AM UTC

jhallenworld wrote: post #11

dmitrygr wrote: post #10

Earlier quoted context omitted.

> an advantage, IMHO it isn't An extra chip means higher cost to produce & assemble board, larger board size, more pins wasted on this nonsense, most fast-edge signals to route, more passives, extra risk to handle for one extra chip being out of stock, and it is much easier to extract firmware than even from a "protected" stm32 Also wasting RAM (and power for it) on code, or random (between high and very high) latenc…

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

Post by lnsru » Mon, Aug 08, 2022, 6:43 AM UTC

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!?

Post by vardump » Mon, Aug 08, 2022, 6:57 AM UTC

Post by the__alchemist » Mon, Aug 08, 2022, 7:23 AM UTC

jhallenworld wrote: post #11

dmitrygr wrote: post #10

Earlier quoted context omitted.

> an advantage, IMHO it isn't An extra chip means higher cost to produce & assemble board, larger board size, more pins wasted on this nonsense, most fast-edge signals to route, more passives, extra risk to handle for one extra chip being out of stock, and it is much easier to extract firmware than even from a "protected" stm32 Also wasting RAM (and power for it) on code, or random (between high and very high) latenc…

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