Description
Describe the problem
Hi all,
I'm experiencing sporadic kernel panics on my macOS (Apple Silicon) system when attempting to flash an NRF52840 board (Seeed Studio XIAO NRF52840) using the Arduino IDE, specifically when the flashing process is executed by arduino-cli. The panics consistently occur during the upload, leading to a system crash and restart.
As it happens so forcefully and frequently (over 20 times these past couple of days) I have noticed that it happens at the following stage:
Performing 1200-bps touch reset on serial port /dev/cu.usbmodem101
I've tried changing ports, USB-C cables and even switched to using a USB-A to USB-C cable via a USB-C adapter (Apple official)
I've got the logs available and will upload one, anyone else experiencing this?
I've never had a crash with an ESP32 board, only the NRF52840 which makes me think there's a driver issue in relation to Nordic.
To reproduce
Steps to Reproduce:
Connect an NRF52840 board to the macOS system (SEEED studio xiao NRF52840)
Open the Arduino IDE and configure it for the NRF52840 board.
Attempt to upload a sketch to the board. (Specify if it's a simple or complex sketch. If it's a specific sketch, include it or a link to it.)
When it gets to Performing 1200-bps touch reset on serial port
observe a kernel panic
The system will kernel panic during the upload process.
In my case there's a crash every 1 in 10 flashes (so far)
Expected behavior
The sketch should upload to the NRF52840 board without causing a system-level kernel panic.
Actual Behavior:
The macOS system crashes and restarts with a kernel panic. The error is a Kernel data abort.
Arduino IDE version
Version: 2.3.6 Date: 2025-04-09T11:22:51.016Z CLI Version: 1.2.0
Operating system
macOS
Operating system version
Sequoia 15.4 (24E248)
Additional context
The crash doesn't happen every time, but is sufficient enough to cause extreme frustration.
I note that the same crash happens via PlatformIO in the same 1200 baud reset step.
panic-full-2025-04-19-230931.0002.txt
Issue checklist
- I searched for previous reports in the issue tracker
- I verified the problem still occurs when using the latest nightly build
- My report contains all necessary details