SAM21D amnesia - Page 1
Forum section: electronics / general

author: earx
author_rank: Newbie
timestamp: July 19, 2025, 05:44:09 pm
content: Hi guys,A pleasure to finally partake in a forum I've browsed for such a long time. As a general EE enthusiast and hobbyist I've worked with half a dozen of microcontrollers over the years. I consider myself experienced, and almost like an old fart. However what I experienced recently really surprised me and also demused me at the same time. I came here to ask if someone else has remotely the same experience, and what they would do about it..My design: I'm built this kit that does videorecording and logging based on a pi5 (video processing, saving.. Linux system obviously) and a microcontroller for the buttons.. nice for PWM LEDs (I never trusted Raspberry Pi PWM, although I hear it's getting better). Both are connected with a 230kbps UART connection (2 traces on the PCB). The microcontroller is a SAMD21. This little bugger is cost efficient, and since I always was charmed by Arduino, of course it had to be an Atmel..Here it comes. So I build a number of these kits.. and most just work fine. Then I had one and after a couple of power cycles it just failed? Wut? Then I opened GDB and guess what? The code section was corrupted in a number of places. A bunch of bit flips? But this is flash memory?? How is that possible? I googled like mad, and all I could find is that you need a good dose of X-rays (more than an airport scan) or a hammer. It seemed to be impossible. But.. after a while it happened again on this same unit! I then replaced the MCU and after a few weeks it happened .. AGAIN!?! .. Everytime in a slightly different area in the flash memory..Then I started to suspect power spikes, and to be honest the startup transients didn't look clean on the scope. But while they seemed to exceed the 3.3V it only happened for a very short time. I don't know how much damage is done if you exceed 3.6V for a matter of microseconds? And how well is my oscilloscope calibrated? Those sort of things cross my mind. As a last resort I just reached out to Atmel (now Microchip) and asked if they could understand what was going on here. Their answer: you need to have a monotonically increasing power supply transient and it needs to ramp up to 100% in about 1 millisecond. If not, then the flash controller can become unstable and yes, even get its memory banks corrupted! I've certainly never heard about this before..Well, in my case that wasn't what happened. The Pi powers the MCU with its 3v3, and it has this little spike at the beginning.. and then after 10 millisecond it finally ramps up to 3v3. And I suspect this is what causes the problem. The thing totally browns out.I read this blog post about brown out detection:https://blog.thea.codes/sam-d21-brown-out-detector/This blogger seems to have experienced the same issues...However, some people say that brown out detection and reset won't cut it. You just need to have a good power up sequence... The irony is. I actually do power sequencing to avoid backpowering the Pi. Would the MCU activate its UART lines too early it could potentially mess up the Raspberry Pi process. Seems like the chicken or the egg.Ok, long story. Sorry guys. Does anyone have a similar experience. Should I just ditch the SAMD21? Should I hold the NRST pin low for a long time using an RC circuit? Curious what you think.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 19, 2025, 07:24:24 pm
content: Hi, I've used the SAMD21 and have very occasionally run into Flash corruption as well. And yes, it was due to the issue described in the blog you mentioned. Once the brownout detector is set up "properly", Flash corruption never happened again.Of course, nobody can't tell for sure if there isn't any other issue in your particular design, but this one is a safe bet. The specificity of the SAMD21 (and I think the same applies to the SAMD51) is that the brown-out reset is not setup "appropriately" for the "nominal" 3.3V Vdd, whereas most other MCUs i've worked with have a sensible default setting that avoids this kind of issues when using them at 3.3V.As to the max Vdd, the DS states 3.63V max and 3.8V absolute max (which is kind of "odd", as most chips on similar process nodes have an absolute max of 4.0V... but that's a small detail). So a very short and small overshoot is unlikely to cause any issue.

author: ataradov
author_rank: Super Contributor
timestamp: July 19, 2025, 08:19:19 pm
content: BOD33 should be enabled in the fuses (User Row). This is the only way to ensure reliable operation and doing it from the code may not be reliable, no matter how close to the reset you put it, some amount of code will run.Or you can hold the MCU in reset externally until your supply voltage is stable.

author: earx
author_rank: Newbie
timestamp: July 21, 2025, 11:09:38 am
content: Hi guys,Thanks for your answers. It's good not to be alone with this issue. What I now also do is just run at 1MHz, setup a systick timer for that CPU clock, setup the brownout detector with reset, and wait a long time until I'm absolutely sure the power ripples have settled.. only then do I switch to 8 or 48MHz. I'll try to setup the fuse as well!Cheers!

author: ataradov
author_rank: Super Contributor
timestamp: July 21, 2025, 02:06:09 pm
content: This is still wrong. You can minimize the effect this way, but there will always be edge cases where this fails.Enabling BOD though fuses is the only reliable way. The reason it is disabled by default is that BOD does not cover the lowest end of the possible operating range, so they don't want to lock out the devices. But if you are on the lower end, then external BOD is required.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 21, 2025, 03:02:50 pm
content: Quote from: ataradov on July 21, 2025, 02:06:09 pmAgreed.Quote from: ataradov on July 21, 2025, 02:06:09 pmWell, just for those who haven't set it yet, BOD33 is obviously a misnomer, the actual level can be set from ~1.7V to ~3.0V.And yes, the actual min operation Vdd is 1.62V from specs and you'd need to run at at least 1.8V (and even that might be a bit too close to the min threshold) to be able to use the BOD. In practice, this is only going to matter for few designs - I've personally never seen any design using a SAMD21 below 1.8V. But you can.Some MCUs have a BOD enabled by default, others not. The more concerning thing with the SAMD21 is that not enabling it can apparently lead to flash corruption even if no code is actively writing to it while Vdd is too low. Something I have fortunately rarely seen in other MCUs.

author: ataradov
author_rank: Super Contributor
timestamp: July 21, 2025, 03:14:14 pm
content: Quote from: SiliconWizard on July 21, 2025, 03:02:50 pmThere was bootloader present that contains code for writing and what code is being run is unpredictable when the power supply is not stable. Triggering a row erase (what we see here) is a very short sequence of instructions.When device is erased or has no code that writes the flash to be accidentally executed, I'm not aware of erase like this. I can't fully exclude it without full investigation though.

author: earx
author_rank: Newbie
timestamp: July 22, 2025, 03:45:04 pm
content: Yep. I have experience with ATMEGA328, ATMEGA644, NXP LPC (cortex M3), RP2040, STM32F042, SAM3X, and now SAMD21. And indeed, the Atmel SAM's belong to the flakiest. De SAM3X also needs to be held in reset for a while, otherwise it sometimes doesn't boot up. But I totally prefer that behavior to what happened with my SAMD21.. According to Microchip the flash controller will indeed not properly initialize and can overwrite its flash. The requirements they gave me for the power supply ramp is pretty strict."Flash memory in MCUs is sensitive to power supply conditions during power-up and power-down. If the VDD rise rate is too slow (below the minimum specified), the internal circuits, including the flash controller, may not initialize correctly. This can lead to unpredictable behavior, including flash corruption, failed code execution, or even permanent damage in rare cases.""If the supply voltage rises slower than 0.004 V/µs, it is recommended to add an RC circuit or another mechanism on the RESET line to ensure the device remains in reset until the supply voltage reaches the minimum required level. Use a ceramic capacitor for better stability, values between 1 µF and 10 µF are typically sufficient. For greater reliability, a voltage supervisor IC is preferred."4V/ms ?? that's a lot. Loads of DC/DC converters start up slower than that. The datasheet has a _maximum_ rise rate as well: 0.1V/us Table 37-5. The datasheet does not specify a minimum rise rate..The RP2040 was also a bit of a weird one. Fast, but with a botched ADC, and no internal flash. I don't really blame Raspberry Pi for it, since they were new to the game and cheap as chips.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 22, 2025, 04:23:50 pm
content: The RP2040 was an oddball but a pretty cool one - and I don't think the RPi ever considered directly competing with other MCU vendors. I think its success for commercial applications came as a surprise. The external Flash is inconvenient if PCB area is limited, and for code protection reasons. But otherwise, it allows very large Flash sizes for cheap and XIP works fairly well on these. Also, external Flash chips are pretty robust against corruption compared to the internal Flash of many MCUs. They also have a pretty robust internal bootloader compared to many others.The RP2350 is much more powerful. The ADC is still not great, although better. But the improved PIO and the B version with more GPIOs are nice. It has a couple issues which may look "unacceptable" for a seasoned MCU vendor (which they are not), but are easily worked around.All in all, although they can perfectly be used in commercial applications, I see great educational value in these, and I think that was the initial intent. Just the PIO and the 2 cores allow for almost endless learning about low-level state machines and multi-core programming, and in many simple cases, they can be used for what would have otherwise required an external FPGA or CPLD.The SAMD MCUs are all quirky in some way. They have a good set of peripherals but have some oddities, like this supply voltage issue, also annoying IO multiplexers with all sorts of limitations that are not always obvious to spot until you read the datasheets entirely.

author: Siwastaja
author_rank: Super Contributor
timestamp: July 23, 2025, 05:29:15 am
content: It's weird how Atmel seems to struggle with "basic" IC design like analog performance decade after decade...AVR microcontrollers were the only thing ever existed I'm aware of where CPU supply injected 8..9-bit LSB worth of noise into the SAR ADC - every other MCU in existence easily delivers at least 12-bit noise-free performance without any special "CPU sleep during conversion" modes. This means 1000x difference in absolute amount of unrejected noise.Or the flaky reset circuitry which plagued the whole AVR series for... at least a decade? Recommendations of separate power supervisor chip were common in early 2000's.Or seehttps://www.eevblog.com/forum/microcontrollers/(pic32cx-sg)-built-in-buck-converter-and-clock-system/. I have never heard of MCU-controlled Vcore buck converter preventing operation of integrated PLLs. Those are literally the features that are almost always used together, and features that would be tested and characterized during chip design as early as possible.No other manufacturer have similar problems with basic power/clock design of their chips.Scary thing with power/clock fuckups are they result in unpredictable flakyness. With STM32 for example you get a lot of errata of internallogicworking the wrong way, but for that there are workarounds which are repeatable.

author: earx
author_rank: Newbie
timestamp: July 23, 2025, 08:19:56 am
content: Yes, undefined behavior is the worst.. especially in hardware. So far my BOD33 code seems to hold. But the problems can arise only after dozens of restarts.. so we'll see. If it doesn't help, I'm ditching the SAMD21 for the STM32F0.

author: Siwastaja
author_rank: Super Contributor
timestamp: July 23, 2025, 09:03:48 am
content: Flash corruption is specifically embarrassing as it is fairly easy to protect against, and every other manufacturer have been quite successful at that, and because failure at this is so devastating; risk of large scale total brickage (non-recoverable) event at end-users.It is as simple as requiring unlock writes in some sort of flash controller key registers, and write any hard-coded factory programming mode in such way that it does not give the unlock command to the flash controller unless it has verified e.g. correct CRC of incoming flashing protocol. Everyone else does this, or something similar.

author: ataradov
author_rank: Super Contributor
timestamp: July 23, 2025, 01:39:56 pm
content: Quote from: Siwastaja on July 23, 2025, 09:03:48 amThere are locks like this. I don't know if they are used in this project. The issue here is that a typical erase sequence is unlock-erase-lock. If you have undefined CPU state and runaway code execution, it might jump right before the unlock and unlock will still happen.