• Interesting results. Looking at the code, it seemed as every place the directory was modified, the DIR_WrtTime was updated EXCEPT in f_open. Here, only DIR_CrtTime was updated. So, figuring that creating the file was the same as 'modifying' it, I updated f_open (in ff.c) to update the DIR_WrtTime as well. The snippet at line 2494 in ff.c is:

    				dw = GET_FATTIME();				/* Created time */
    				ST_DWORD(dir+DIR_CrtTime, dw);
    				ST_DWORD(dir+DIR_WrtTime, dw);  //TWS: Added to init modification time too!
    
    

    This worked, whenever I created a file, both modification time and creation time showed correct values in Windows File Explorer. If I updated a file that had a previous messed up file date, the modification date was updated to a proper date. I thought I had tested this case with the first build I did with your fattime.c update, but I guessed I missed this case.
    So, it appears with this last change, the SD card file timestamps are good.
    UPDATE: I think I may have done a partial build with your first changes and ff.c hadn't been rebuilt. That may explain why my first build didn't seem to fix the creation time problem.

    It appears, however, that fs.statSync() assumes that the file timestamp is GMT time, not local time and then adjusts it for localtime. (I'm GMT-0500). This is not tragic and might even be reasonable, although Windows and Linux assume local time.

    Finally, as an FYI, I realized that the default clock rate was 100KHz, not 1MHz as I had thought. I changed this in my SPI1.setup({baudrate:1000000}) and the SD card write appeared faster, but I'll measure that shortly. 100KHz is probably a safe speed for old SD cards (250KHz should be the limit initially), but today's SD cards are much faster.

About

Avatar for TomWS @TomWS started