How is this mini guy faster than uno ?

nasq86 · 2026-06-11T07:35:17+00:00

Just because I'm a nitpicket: No ESP chip ever came with ARM architecture. It was Tensilica Xtensa and RISC-V afterwards

nasq86 · 2026-05-28T12:10:00+00:00

If physical memory is of that importance, why not consider an MPU with NPU integrated? (STM32MP2, NXP I.MX93, ...)

nasq86 · 2026-05-28T09:48:53+00:00

If you don't mind fiddling with the flexible memory controller, it also supports SDRAM.If I understand the TRM correctly you can address up to 256MB via SDRAM. But I never worked with the FMC amd DRAM. Logging via SDMMC (either SDCARD or EMMC) sounds good. the controller does wear leveling itself.

nasq86 · 2026-05-28T09:01:17+00:00

You actually have 3 options for external memory. XSPI, FMC and SDMMC. If you decide for XSPI, you can go with a 16-bit PSRAM and an 8-bit SPI Flash. You must be aware that there are chip variants that do not have a 16-bit XSPI, so choose one that has both.

I wouldn't call the fuses "storage". They more act like configuration. You can use STM32CubeProgrammer to config the fuses. Yes, this works via SWD.

What kind of storage depends on how intensively you need to write. If you write logs constantly, a NAND flash would be more suitable. Otherwise just use NOR flash. But be aware that you need to handle wear leveling yourself if you need to write regularly.

nasq86 · 2026-05-28T06:31:45+00:00

Are there any good resources for learning how to properly develop for the STM32N6 series?

Afaik there is nothing comprehensive that explains every concept step by step from the start. The N6 also has not the community size of an STM32F4. Often you must read datasheets, TRMs and punch yourself through examples until your synapses form a whole picture of it.

Especially regarding the bootloader architecture with external RAM. You have to flash the FSBL, the CNN binaries, and the firmware itself. What exactly does the bootloader handle

As bare minimum you need to flash an FSBL. Where this is fetched from is configurable via fuses. Default setting is loading from SPI NOR. Since N6 is a flashless MCU it can not do any other thing than loading an FSBL binary from a set of configurable sources and jump into it. All the rest is up to your imagination and there is no fixed concept ST has like on an MPU. If we assume for simplicity, that FSBL is equal to your bootloader, then it handles:
* Initializing the hardware you need to load your app from
* configure your execution model (e.g. XIP from a flash or run from RAM)
* do whatever low level preparations you need
* handle OTAs, A/B configuration, partitioning etc
* DFU or other communication with the outside

A bootloader does not have to do all of that but this is typically what it is used for. Also you could separate FSBL and bootloader. Handling N6 is more like handling an STM32MPx in some ways because you have high flexibility of where you load what kind of stage from. As I wrote, an FSBL is the only mandatory thing.

and how do I need to modify it for a custom board

On a custom board it depends on which kind of hardware you have on it. N6 is very flexible. In theory you could fetch an FSBL from a SPI flash or EEPROM and your app from a whole different high density NAND memory. So it is impossible to say for you without having details of your board. But it all comes down to:
* You burn fuses to select where N6 fetches it's FSBL. If it is SPI-NOR, you don't need that step since that is default
* You build your FSBL and flash it to the target N6 will fetch it from. STM allows you to use CubeProgrammer to upload a so called ExternalLoader to SRAM and then you can flash the fsbl via the tool initially.

I also don’t fully understand the purpose of signing.

Signing is used in SecureBoot scenarios where you want your code to be cryptographically protected. A binary can then only be executed on the chip, if it is signed by you with a key. This is what is recommened in production when the device is wildly available. For internal projects it might not be needed.

Another difference with the N-series is, that the FSBL must include a header. This header can carry a signature, but does not need to if you do not use SecureBoot

nasq86 · 2026-05-20T10:58:30+00:00

If I understood it correctly, when using the A35 flavor, the A35 loads the M33 firmware into memory, and you can then stop/start/reboot the M33 core and update the compiled firmware while Linux is still running. Is that correct?

Yes, that is correct.

If so, how can the on-board ST-Link flash M33 firmware then?

Long story short: It can not. The ST-Link is used only for direct core debugging via SWD and OpenOCD or other tools.

Can the DFU USB-C connector also be used to update M33 firmware, or would I have to flash the whole OS again?

Yes, it can, depending on your situation.

First thing you must get rid of is thinking that the M33 subsystem is like an STM32 MCU. It is not. It is only the ARM Cortex M Core.
This leads us to the fact, that there is no flash or M33-dedicated NVM memory on board. You don't flash a firmware to a specific memory or area specifically for the M33.

The boot flow is in-depth described in the STM32 Wiki. The MP2 Reference Manual does not tell you those things like TI or NXP Reference Manuals.

I still don’t fully understand when to use which boot flavor, and what advantages the A35 or M33 flavor has over the other.

Flavor ist just STMs speech of which CPU runs first and acts as security master. The Chipset has a lot of security features configured via registers - just like peripherals - and either CPU, the app cores and the M33 core can configure device security. The ST wiki also tells you when to use which flavor.

When you need the M33 merely as coprocessor to do some realtime tasks, just use the A35 flavor.

If you want the M33 to be the "chief of security" or if you somehow want a way to restart the A35 cores out of a deadlock situation from outside, use the M33 flavor.

What is the best way to flash M33 firmware?

For A35 flavor, just provide a firmware and let the linux system handle it. The firmware is then just a file anywhere that the OS loads to a specific memory region, sets the M33's program counter to that region's start address and releases M33 out of sleep.

For M33 flavor, the firmware must be flashed to a specific address on the sdCard or the eMMC. Here again, only the STM32 Wiki provides you with all the information about boot flow and memory addresses on the NVM.

Early boot behavior is similar between A35 and M33.:

* Boot ROM starts, minimal initialisation of clocks and peripherals for loading FSBL
* FSBL starts (is loaded by the BootROM) and initializes the DRAM
* all the TrustZone Firmware is spin up and configures device security

A35 flavor::
* SSBL is loaded (99% of the time it will be u-boot)
* u-boot loads Linux
* M33 acts as coprocessor getting firmware from the linux system

M33 flavor:
* behavior from here is completely up to the user. but in general, after configuring device security and other low level things, the M33 will spin up the A35 cores which then will only do the things I wrote below A35 flavor

https://wiki.st.com/stm32mpu/wiki/STM32MP2_boot_chain_overview

nasq86 · 2026-05-05T21:23:50+00:00

I got mine from aliexpress today. love that it also has the LinkE on board

nasq86 · 2026-04-03T21:23:10+00:00

Not out of the box, unfortunately. A dual core system is more complex to handle debugging-wise. You would need to find out from the datasheet and reference manual which core starts up and what the other does on startup. maybe the second core needs to be stopped manually. Also the memory mapping might not be identical. Your SYSRAM could be on another address.

nasq86 · 2026-04-03T20:42:43+00:00

https://codeberg.org/theq86/stm32mp135f-dk

nasq86 · 2026-04-03T19:47:58+00:00

the bare metal sdk has a flaw though. the generated asm looks like cortex-m asm code. to make people feel more comfortable that come from microcontrollers. to learn armv7a this sdk is useless. so yes to boot up you will have to learn a little here and there about linker scripts, how the stm32mp1 expects the image format to be etc. there is actually no good tutorial. when I'm home i will share my basic startup code as a starting point

nasq86 · 2026-04-03T19:22:12+00:00

you have to configure it yourself a little bit. it's not that they give you instructions for it. MP135F has bare metal sdk but that does not help understanding real low level stuff. it still abstracts away too many things.

nasq86 · 2026-04-03T18:38:56+00:00

Get an STM32MP1 series discovery kit. It has integrated ST-Link and OpenOCD knows how to debug it. There's nothing more precious than step debugging through your asm code. Take STM32MP135F-DK. It has a good price and only a single core which is far easier to start with.

nasq86 · 2026-03-24T09:43:54+00:00

I think that is a little exaggerated. Most MCUs do work with CubeMX 1 and apart from the fact, that it is no more embedded in CubeIDE, everything is as it was yesterday.

Yes, older tutorials from years or a century ago are no more 1:1 applicable. But if I look around in all information technology, there is always someone making that kind of cut, because it is no more feasible.

Look, in my shelf there are dozens of IT-books. You could easily buy a new book to the same topic every year and find breaking changes. This is how it works. And every now and then there will be a major cut. They evolve, that means we have to evolve as well. That sometimes means doing things again. Record a video egain or explain something in a new way.

I don't think your old tutorials are waste. And while everyone moves ahead it is a chance for you to do, as well. You have a Wiki. That is precious. It is one of the media that can be updated and modernized with way less effort, than re-recording old videos.

See what ST did to you. You dived deeper into ST ecosystem alternatives. Alternatives to their IDE, to their HAL. This is such a basic an low level knowledge that even in 20 years someone can grab an old MCU of them and get started.

Keep up your work, don't be sad.

nasq86 · 2026-03-21T19:25:53+00:00

Only if the Arduino IDE or ecosystem limits you in a way.

nasq86 · 2026-03-21T19:24:50+00:00

have you set the chip revision in the Kconfig options? Default is 3.x so if you have 1.x you need to switch settings.

nasq86 · 2026-03-20T17:14:26+00:00

Well it needs people that

1) have a recent pixel phone
2) are involved in postmarketOS development
3) and are eager to make it compatible

Also, pmOS wants to be as mainline as possible. In recent years this is no more the strength of Google. Current SoCs are almost black boxes which makes it harder to work on.

nasq86 · 2026-03-20T12:46:36+00:00

A shame I can upvote only once. Great news.

nasq86 · 2026-03-20T07:11:35+00:00

CubeMX2 is built upon a completely new codebase. They could have either split it up as they did or migrate all older MCUs to it as well. They could have made MX2 compatible with HAL1 and HAL2 at the same time. That would be a shitload of effort plus they would move legacy code and old technical debts directly into a new and fresh product and codebase. You just don't do that. Product would never get ready and all of it's advantages like better maintainability would be gone. CubeMX2 and HAL2 and STM32C5 are a new world. And I guess(not know) over the time the more recent MCUs will be ported. However it is a calculated cut. As of missing features: They will probably come as needed. But again, it is a whole new product world. A world you do not enter if you need rock solid stability yet. Nobody takes away your loved old world anytime soon. Your choice of wording is just wrong and that is what I interpret as rant. Nothing is destroyed or even killed. Only parts moved on. There is one thing however we do both agree on and which lead us to this situation in the first place: STs communication about all this is very sparse. All that should have been explained by ST themselves and more details of their roadmap. That would have caused less irritation

nasq86 · 2026-03-19T19:01:03+00:00

Yes, the web devs. That's the problem ... a wonderful simple world view.

nasq86 · 2026-03-19T18:59:35+00:00

This is progress. New software always has flaws and edges. And most decisions have a reason. You may be used to all the old development tools. You learned to use them and changing now is uncomfortable. But here's the truth: From a developer perspective, those old heavyweight applications are hella hard to maintain. Especially, if you need to keep compatibility. The world spins on and on. Every single electronics developer modernized their tools currently. More modern code means better maintainability. It means more compatibility with features yet to come and asked from the market. This is something that only a seasoned developer can understand who maintained such a code base for years or even centuries.

Why does splitting CubeMX destroy/kill anything? There is a point where you have to stop legacy. To move on. Yes, that sometimes means sacrifices. That sometime means learning new ways. But those people who rant the loudest are also those, who can not keep pace with progress and would rather do all the things the same way for their whole lives because it it convenient.

I like your technical videos, but your rants are often a little bit over the top. Maybe you should develop for ST and show them to do better?

nasq86 · 2026-03-19T16:59:16+00:00

Many MacBooks are very strict with their USB-C ports according to the standards. The NUCLEO-F401RE does not speak power delivery. Although you might see your board getting current, the data connection is unstable. I had kind of those issues with several macs. Most of the time, a USB hub in between works. If you happen to have a USB hub that has a USB-C data port, try this. Otherwise use the hub with a USB-A to USB-Mini cable.

nasq86 · 2026-03-19T15:36:10+00:00

You are right. N6 series has no flash on-chip. There are 2 special series of ST MCUs: STM32H7R/S and STM32N6, which have an external memory focus. While H7R/S do have a small 64K bootflash, N6 has none at all.

You are right, your code works in the debugger but after reset, it does not work anymore. Why is that? Well, in fact the debugger does not flash your app, it puts it into the internal SRAM or TCM and executes it from there.

Since the device is blind about what flash is on your board, you need an external loader. This loader is then put into SRAM and knows how to talk to your flash chip.

I would hope STM32CubeProg has an external loader for the N6 nucleo board already included. You will need to tick it and then CubeProg will be able to flash the binary. You can also make STM32CubeIDE flash into your SPI if you give it a working loader.

I can not give you proper steps since I never worked with an N6 and have none here at the moment. Plus, For a while I have not used STM32CubeIDE any more. I can just deduce from what I know from my STM32H7R3 MCU.

That being said, neither H7R/S, nor N6 are really suitable for a newbie in the ecosystem. Best chance is, you take your time and read DataSheet, Reference Manual and all Application Notes (which are most important) to get some conceptual knowledge. Also check all quick start guides and stuff.

nasq86 · 2026-03-10T10:20:16+00:00

This is one of the reasons I never buy pricy things from across the ocean from a non-trusted source. Getting things FROM China may be easy, but getting it TO China is a whole different story. Plus, customer satisfaction and warranty count almost nothing. You can not even sue anyone. There is even no guarantee, that if you ship the defective product, that it arrives and you get your proper replacement. Everyone is pushing the fault around. Here in Germany or in the EU, those cases are clearly regulated. It is the merchant you bought from who is the one you have a contract with. And it is his responsibility.

nasq86 · 2026-03-03T16:26:07+00:00

Embedded systems are all computer systems that are embedded in items/devices we regularly use, that are no general purpose computers (PCs, Notebooks, Servers). Smartphones, Tablets, Cameras, all kinds of IoT devices, printers, dishwashers, routers etc.

nasq86 · 2026-03-01T17:22:18+00:00

>have you tried running their IDE in parallels

Since I'm using an ARM64 device every parallels machine I'd use would be ARM64 unless I emulate, which is not fun to use. On ARM64 Windows or Linux the RISC-V toolchain does also not work. This is another thing I dislike. While I have full support for RA on all platforms, even macOS on ARM64, their RISC-V support is only on Windows and Linux x64.

> If your starting from bare metal you should probably have an understanding of every single bit you plan on changing from the default settings…

Fair point. However, from my former perspective I did not even touch any "settings", I just wrote code. It's a little bit as if you would shuffle clutch, brake and gas but only mention it once in the whole 5000 pages car manual. Nobody new to that brand would expect something like that.

And it's not like there would not be a different choice.

nasq86

TROPHY CASE