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.