STM32CubeProgrammer on Apple Silicon

[apullin]

Has anyone experienced issues trying to run STM32CubeProgrammer on Apple Silicon, and overcome them?

I am trying to use it to flash to an STM32F103 micro, but the flashing fails partway through.
The issue reproduces using the CLI version of STM32CubeProgrammer, too.

Using STM32CubeProgrammer with the same fixture & target on Windows works fine, though.

Notably, it looks like STM32CubeProgrammer bundles its own JRE, and is an x86_64 executable - so this whole thing must be running through the x86 emulation layer!

I tried opening a tech support ticket with STMicro themselves, asking if a build for Apple Silicone is available or will be any time soon, but they're stuck on asking me about what kind of USB cables I am using ... an abject dead-end there, for sure.

[Nawres GHARBI]

Hi @apullin 

you may see it as an abject dead-end but as you are wiring many convertors in serial it may causes some com latency ! 

We are currently testing with the exact same setup, stay tuned for the results. 

Regards

Nawres

[apullin]

Nope, that's not it.

The crash dump I provided showed *clearly* that it was inside the JRE, which is easily verifiable as an x86_64 JRE.

The open-source `stm32flash` tool also failed. But why? It was using the "Extended Erase" command, as documented in the bootloader...

Well, it turns out that STM32CubeProgrammer only erases up to 100 pages at a time on Extended Erase, at least on an STM32F103 XL-density part with BL protocol 3.0 .
And I had to install on a Windows machine and use a COM port sniffer to find that little detail.

Now, is *that* quirk documented anywhere? In any errata sheets? Not as far as I have found.

But at least I could patch `stm32flash` with that secret limit, so that it now works, so that I can flash from an M2 MacBook.
Even through exactly the same "many converters in serial" (which are just pin scramblers and an ordinary USB-to-VCP bridge IC), hitting the same block device for the serial port.
Which proves that it isn't a COM latency problem.

[Houda GHABRI]

Hello apulin,

Using the same setup, we are able to reproduce this issue in M1 Apple and FT232R  fixture.

The CubeProgrammer development team is working  on resolving the issue and delivering a solution as soon as possible. I will keep you informed of any progress or update.

Internal ticket number: 159134   (PS: This is an internal tracking number and is not accessible or usable by customers).

Houda