Hi there, no I haven’t been able to figure out a solution 
Oh I think I’ve gotten a few MG24’s into this state, but it’s a little different now, so this is a new one.
They are now getting stuck in a state where the firmware still functions (goes to sleep, wakes up, displays the correct stuff on the display) but nothing new can be written to it. This includes any new put actions to EEPROM storage, and also new firmware updates. It’s interesting, the IDE says that it successfully uploads the sketch, but it definitely doesn’t. Crazy! Wish I knew why this was happening.
I was definitely using the wrong buck converter before (a 3v) which seemed like it wasn’t providing enough power and causing the EEPROM to mess up. I am now using a 3.3v buck converter wired up to the gnd and 3.3v pads on the back. I thought this was working better but I’m wondering if maybe it still isn’t exactly enough? Maybe I should try a 3.7v, or maybe I’m chasing the wrong thing here…
What firmware are you programming onto the devices? I could try getting one of my MG24’s into a similar state to try see what is going on?
I can generally still modify (Non volatile “flash” memory) on an MG24 down to 1.8V (lower possible but risky).
EEProm - not sure what you mean by this? Do you have separate EEProm on the device? Or did you mean the on-board flash?
Oh, okay bummer. Seems like it isn’t a voltage issue then. I just mean the on-board flash.
Hi Dave_Reese,
I consulted Seeed’s tech support about the problem, but it couldn’t be easily resolved, so I had it replaced.
1 Like
So is it a factory/supplier fault on a particular batch of boards?
I wanted to overwrite the SAMD11 firmware using JLink, but tech support suggested replacing it.
The cause of the problem is unclear.
On a different note, nRF54L15 has been released. Looking at the circuit diagram, it appears that SAMD11 is implemented in the same way as MG24, but a level shifter UM3301DA has been added to SWDIO. Could this be related?
Replacing the firmware or hardware?
I have been working with @Dave_Reese on this and I can’t find any issues. He does use Deep Sleep and IMU but can all be recovered “normally”.
I’m wondering if something else is causing the failure, like using PA1 or PA2 on the 'MG24 - or a catastrophic hardware fault?
Looks like just an isolation exercise when USB is disconnected?
Do you know how he recovered?
Since parts that were not included in the MG24 have been added to the newly designed nRF54L15, I wondered if there was something wrong with the MG24.
EDIT:
It is also strange that it has not been added to SWCLK.
He hasn’t (yet 
). I ran his code here on my hardware.
I’ve been using them extensively for a while now on many projects and haven’t had any issues.
Probably due to the fact that the SWCLK is output (from SAMD21) only?
I noticed something when connecting JLink to the pad on the back. When USB is connected to XIAO, power is supplied to SAMD11. If JLink is also connected at the same time, in some cases, SAMD11 and JLink’s SWDIO and SWCLK may conflict. Do you think this is a problem? Or does SAMD11 remain in Hiz mode until CMSIS starts up as a debugger?
I’ve only noticed that when I’m running GDB over OpenOCD via the USB/SamD11 CMSID Dap interface.
Most of the time they seem to be able to “co-exist” without issue. So both connected only one “in use”.
Hi,
@msfujino I have the same issue on my device.
I was playing around with the clock manager configuration in Simplicity studio, trying to optimize the power consumption of the device and… looks like I broke something. After flashing, the device does not respond anymore and OpenOCD now returns errors when I try to erase the device or any thing else:
Open On-Chip Debugger 0.12.0+dev-01514-g21fa2de70 (2024-02-07-19:19)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
debug_level: 2
Info : auto-selecting first available session transport "swd". To override use 'transport select <transport>'.
efm32s2_dci_read_se_status
Info : Using CMSIS-DAPv2 interface with VID:PID=0x2886:0x0062, serial=D75A6F9E
Info : CMSIS-DAP: SWD supported
Info : CMSIS-DAP: FW Version = 2.0.0
Info : CMSIS-DAP: Serial# = D75A6F9E
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 0 TDO = 0 nTRST = 0 nRESET = 0
Info : CMSIS-DAP: Interface ready
Info : clock speed 1000 kHz
Info : SWD DPIDR 0x6ba02477
Info : SWD DPIDR 0x6ba02477
Warn : Connecting DP: stalled AP operation, issuing ABORT
Info : SWD DPIDR 0x6ba02477
Error: Failed to read memory at 0xe000ed00
Error: [efm32s2.cpu] Examination failed
Successfully connected to DCI
DCI WPENDING bit set, retrying
DCI WPENDING bit set, retrying
...
DCI WPENDING bit set, retrying
Error executing event examine-fail on target efm32s2.cpu:
Warn : target efm32s2.cpu examination failed
Info : starting gdb server for efm32s2.cpu on 3333
Info : Listening on port 3333 for gdb connections
Error: Error connecting DP: cannot read IDR
Nothing solved the issue up to now. Putting PC0 to ground before reset/power up nor running the recovery script provided by SEEED neither a combination of both.
Hi Matthieu_Charbonnier,
Please also refer to the link below. It seems to be slightly different from my symptoms.
Have you tried connecting the debugger to SWDIO and SWCLK on the back of the board?
Can you elaborate on this?
What firmware did you use to get to this state?
Well,
@grobasoz I’m not sure how to answer this question, I’m developing a zigbee sleepy end device. Well it works, I was trying to tune the consumption and in the process, I … eventually disabled the HFXO. Since then, I’m not able to flash the device anymore.
@msfujino I plan to use a SEGGER J-LINK device to try to recover it, I just have to get one.
But, sorry I don’t want to pollute this thread with my problem, I thought my device was in a similar state though the way I took to get there is different.
1 Like