XIAO mircoSD programs - run once but won't reboot

I’m successfully able to run the example code in the Arduino IDE, read and write to an SD card, but when I reset the board (either manually or with the button on the expansion board), it doesn’t reload the code. Is there something that I need to do to handle restart cleanly?

Steps to reproduce the problem for me
1 - open CardInfo example
2 - change chip select to 2
3 - compile and download
4 - get appropriate response on serial monitor
5 - reboot
6 - nothing

What am I missing?

For the sake of completion, I can run a blink example like the one here (Overview of the SAMD21 Arm Cortex-M0+ Based Seeeduino XIAO), and it downloads, runs and reboots as expected.

i was just wondering if it were possable to load and execute a program from sd like a real computer

it seems this is what you are doing i would like more information of how you are doing this

thanks… peace

Actually I’m trying to write a really simple data logger that will store sensor (barometric pressure) data on the miroSD as quickly as possible. Also, I’ve seen your thread on the “load from card” topic and am following it in case you get a good answer.

I did some more troubleshooting Friday afternoon, and I stand corrected. The Blink application only runs sort of as expected. When I reboot, it flashes the LED properly, but it doesn’t reconnect to the serial monitor. This sounds like it aligns with some of the other serial monitor threads (if you have an especially favorite one, please drop a comment - otherwise I can do my own research on this topic).

The serial monitor issue appears to be the problem, not the SD card writing. Crisis somewhat averted.

i think the way the code is wrtten it waits for the serial monitor to connect… so if you reboot yu will still need to close the serial monitir and reconnect to the device before it will proceed

there should be a wait loop in the serial connect, if you change that it should obviously not wait for serial to connect

1 Like

@cgwaltney - I’ll copy the basic “blink” code below that I’m working with, but it doesn’t use anything blocking in the setup. It actually doesn’t even use the Serial.begin() function since the SAMD21 does that function in the background with USBSerial automatically. Adding it back in doesn’t change behavior.

It does look like closing and re-opening the serial monitor brings the link back to life. I guess it’s a fragment of how the chip does the soft USB serial connection.

#include <Arduino.h>

// Use an asymmetric delay to confirm that the LEDs are active low.
// Change the delay values to confirm that a new version of the firmware has been uploaded
#define SHORT_DELAY    25 // 1/40 second on
#define LONG_DELAY   1000 // 1 second off

void setup() {
  pinMode(LED_BUILTIN, OUTPUT);  // yellow LED that will be flashed
  pinMode(PIN_LED_TXL, INPUT);   // turn off the USB activity
  pinMode(PIN_LED_RXL, INPUT);   // LEDS to better see the yellow LED

int n = 0;

void loop() {
  n++;                              // increment the loop counter
  digitalWrite(LED_BUILTIN, LOW);   // turn a LED on
  Serial.printf("%d: ON... ", n);   // say so on the serial monitor
  delay(SHORT_DELAY);               // wait
  digitalWrite(LED_BUILTIN, HIGH);  // turn the LED off
  Serial.println("off.");           // say it is off and terminate the line
  delay(LONG_DELAY);                // wait
}                                   // repeat the loop```

Interesting, i am not an expert, and i didnt know about the soft usb serial, but i think the command i was thinking of was the "while(!SerialUSB) " was the command i was thinking of, but commenting it out didnt change, i think this portion is supposed to pause execution until a serial monitor is opened so data will not be lost

void setup() {
// Open serial communications and wait for port to open:
while (!Serial) {
; // wait for serial port to connect. Needed for native USB port only

When you’re debugging, you put that line in so that the code waits until the serial connection is active so that you don’t miss any potential messages. It’s especially important if you’re trying to debug your startup routine, as with this chip specifically it can take up to 10 seconds for the serial connection to initialize.