⚠️ NOTICE - AUGUST 1 2024

[maholli]

Note

We are posting this summary to notify the community as quickly as possible.
These are just preliminary findings, interpret it however you wish.

We have found the ATSAMD51 microcontroller used on PyCubed Mainboards (v00 - v05) exhibiting a surprisingly high sensitivity to 50MeV protons. Our KickSat-2 and VR3X missions had zero issues with the ATSAMD51 and the part does have some radiation literature. But after troubleshooting unexplained reboots on our recent PY4 mission, we decided to test it ourselves.

It's quite possible the ATSAMD51 has undergone some manufacturing changes in the nearly 10 years since it was selected for PyCubed that introduced new avenues for rad susceptibility (Atmel acquired by Microchip, chip shortage shaking up fab availability, etc). Additionally, much of our personal flight heritage with the part has been during different periods of the solar cycle and not subject to the high bursts of proton fluxes currently observed in the 2024 solar maximum.

In our testing, all of our test articles (all use ATSAMD51 with date codes within the past two years) will consistently experience latch-up of one or more peripherals when exposed to 50MeV protons to a fluence of 5E8 p/cm2 or less. We saw this manifest as many things such as halted serial communication (SPI/I2C/UART) but continued external watchdog PWM, or latch-up of certain GPIO power domains (groups of pins) while continued operation of others. Suffice to say when we release a v06 PyCubed Mainboard design, it will not utilize the ATSAMD51 microcontroller.

It is worth mentioning that, with the culprit ATSAMD51 masked from the beam, the remainder of the PyCubed bus operated without issue under accelerated exposure until we ran out of time on the beam (equivalent to multiple years on orbit), including power, RF, sensors, etc.

[cadenhillis]

Hey Max, thanks for the candid update.

Are there any wishful / current contenders for the SAMD51 replacement? I've been keeping my eyes out for any due to frustration with the poor support for the device post-Atmel acquisition (in close to the metal/RTOS applications).

If you need any assistance with v06 design, I'd love to contribute.

[mjcampy]

Hi Max - radiation effects engineer here, interested the news. Curious about the choice of proton energy for test and categorization of the sensitivity: SEL vs. SEFI. Happy to connect and help if needed.

[maholli]

Dr Campola, what a treat! I hear we are at the same conference right now. I'd love to chat! I'll reach out privately so we don't have to post contact info on the forum.

[syedkarim]

Hi Max. Do you have a short list of possible replacement to the SAMD51?

[maholli]

@syedkarim I have two candidate MCU in mind: RP2040 and STM32H723ZG. I have fully functioning PyCubed boards for each MCU on the bench. I will be doing some preliminary radiation screening (400MeV protons) in early September and will report back.

[ihateAPEuro]

Hey @maholli, do you mind sharing the specific MRAM you used with the RP2350 board in the attached image? We are looking for memory that would be compatible with the RP2350 and you seem to have been successful in your testing. Thanks!

[maholli]

I've used QSPI MRAM offerings from Everspin and Avalanche without issue on the RP2040 and RP2350. You'll need to compile your firmware to properly inform the 2nd-stage bootloader how to use the MRAM, since they are typically not instruction compatible with the NOR flash devices found on the various dev boards (pico, feather, etc).

[ihateAPEuro]

I appreciate the swift response!

[yspacedev]

@maholli do you have the test data for the RP2350? I'm part of the Rice University OwlSat team, and our current plan is to make an RP2350 and Pycubed based CubeSat for our mission!

[mlyle]

@yspacedev @maholli @ihateAPEuro Open source now-- the NyanSat team's variant of PyCubed. https://github.com/OakwoodEngineering/ObiWanKomputer

What's changed? RP2350; MRAM+PSRAM; two solar charging paths for bigger satellites. BOM changes to be more easily produced now. Almost all components on one side (just some castellated modules/connectors on the bottom). 40 pin stacking connector. Also, a novel supervisory circuit that will power cycle most of the board if the microcontroller doesn't create a "proper" pulse train.

Biggest thing we gave up was the little spots for payload modules, but we have area on the bottom and may reintroduce them.

Also, there's an associated stacking "combined payload board" which has a whole lot of analog and high-power I/O, and houses a PiZero2W for imaging.

[tobiadetula]

Hi @maholli , I was wondering if you’ve decided on an MCU candidate for the PyCubed v06, and if there are any current plans or timelines for its release.