Erase Flash, burn bootloader functions not working on Macbook M1 laptops

Hello,

I had been working on platformIO framework to develop firmware for my product based on nrf52832 microcontroller and I recently started working with the Macbook M1 laptop. I realized the platform functions such as erase flash, burn bootloader didn’t work (stuck in forever loop) on the new laptop (Attached pictures below). The upload function works though. Any assistance would be appreciated.

Thanks!

I am using a Mac Mini M1 running on Monterey
I am able to upload but it takes forever (hang) to erase.

Are you uploading via regular USB serial convert (esptool.py) or some debug probe like a JLink?

The upload process takes place through JLINK probe, I have since moved on to using a Windows PC but the issue still seem to persist, is there any recent updates on this issue?

The issue being, it says “Erasing…” but it never finishes, right?

Yes, the process gets stuck at “Erasing…”, I’m assuming it might be a compatibility issue with the cli tool and M1 processor, since these processes work perfectly on Windows and Ubuntu

Hey @maxgerhardt, I am still facing this issue and would like any assistance on this, thanks!

I have no answer, but maybe a tip to help move the conversation along…

If they are, we’d know the problem. Esptool works best on Espressif boards. :slight_smile:

(We know, Max - you work crazy hard here and it’s easy to overlook things and damned hard to have the breadth of knowledge you have. Just ribbin’ ya.)

I can report that esptool works lovely on my MBP-M1. I’m not sure how useful that is, though.

If this was on my desk, I’d turn on verbose mode,

pio run -v --target upload -e $BLABLAH

and wait for words to scroll by. Eventually, Platformio will try to run a little bit of Python somewhere (maybe it’s scons, but scons is is python…) that will ultimately shell out to some kind of a tool from your board maker or someone that will probably contain a big argument list that includes the path to the binary yuo’re uploading, any options, and the device name that it’s uploading to. If it’s a serial port, for example, you’d want to check that the serial port is sane.

Oh, wait, that reminds me. Maybe I CAN help. My Macs (all of 'em) create “serial” ports for the bluetooth interface for every pair of earbuds/headphones they’ve ever met. PlatformIO doesn’t go and ask IOKit what devices are installed and actually available, it tried to upload to ALL OF THEM and when it hits these fake BT ports, it locks up. The solution is (to not use PlatformIO to upload boards) and either nail the device to one fixed /dev name or just have a little external script that runs ioreg -l | $(some awk or perl to find them) ports that then sets $PLATFORMIO_UPLOAD_PORT and the associated monitor port and THEN calls pio run --target upload -e $FOO and/or pio device monitor -e $FOO.

I’d forgotten about that until I started typing since that “discovery” was on about my first day of PlatformIO. I’ll bet that’s it, though. It just further convinced me that the team maintaining the code didn’t use Macs, didn’t use headphones, or didn’t use boards with serial ports.

OTOH, if you think it really is talking to a sane /dev/cu.SOMETHING that should work and your board upload is locking up, you should probably talk to the maker of that board loader which is probably EspressifNordic. :slight_smile: