Hey @KillaCycle (Customer)​ ,

It looks like you are using the correct SD card library, I use the default one as well.

If you remove the SD card related portions of the code, do you still see the lockup?

Are you able to provide your code for review? If you cannot post it here you can send it to me at adamc@facts-eng.com

Thanks

Adam

I removed the SD portions yesterday. It has not locked up _yet_ today...

I compiled the unedited example data log code from the P1AM github. It does not show any warnings. However, I then recompiled my original code and it still shows these same warnings.

I copied and pasted these identical SD card routines that have run for years on several different platforms such as Teensy, Mega, and Nucleo. Something is not quite the same on the P1AM platform I suspect.

Here is the snippet of code (copied from Adafruit) that I use to find an unused log file number, open the new file, and assign the file handle.

if (SD.begin(chipSelect)) { // See if it can be initialized

    if (DebugFlag) { // if the debugging flag is HIGH, then print useful stuff to the monitor

      Serial.println("SD card is in slot and is ready. File number and name is:");

      }

     snprintf(filename, sizeof(filename), "kiwi%03d.csv", SD_LogFileNum); // includes a three-digit sequence number in the file name

     //P1.stopWD(); // Pause the watchdog timer to prevent it from triggering.

     while(SD.exists(filename)) {

       SD_LogFileNum++;

       snprintf(filename, sizeof(filename), "kiwi%03d.csv", SD_LogFileNum);

       }

     //P1.startWD(); // Start the watchdog timer again.

     //P1.petWD(); // Reset the watchdog timer to prevent it from triggering.

     dataFile = SD.open(filename,FILE_READ);

I'm using a uint32_t for the variable SD_LogFileNum. Might that be the problem?

Again, thanks in advance,

Bill D

I wouldn't expect the SD_LogFileNum data type to be an intermittent issue, especially since your sprintf formatting keeps it fixed size and the actual call to the library is on "filename". I see the compiler warning worrying about unaligned access on "DirectoryEntry" but I dont see that on your code snippet above. I tihnk that could be something worth correcting, since that could cause an architecture dependent error as the SAMD on the P1AM is different that the NXP, AVR, and STM32 you've had this work properly on.

A quick fix for alignment is to use the gcc code to force it on your declaration like below:

int aligned_word __attribute__((aligned(4))); //aligned on 32 bit boundary.

I'd also check to see what version of the SD card library you are using to see if there are any regressions or corrections that could be related to this.