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
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
@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() {
//SerialUSB.begin(115200);
//while(!SerialUSB);
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:
Serial.begin(9600);
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.
