SD Card file timestamps are always 1/1/2077

[espruino-discuss3]

Posted at 2019-03-04 by TomWS

I have set the IDE communications option to set the time on the device and confirm the correct date typing Date() on the console. However, when I create a file on an SD Card, the timestamp is some constant value (Jan 1, 2077 12:00AM).

Is there something I need to do to have the filesystem keep track of modification times?

[espruino-discuss3]

Posted at 2019-03-05 by @gfwilliams

I just checked and it wasn't actually implemented. I've just (hopefully) fixed that so if you try a cutting edge build you should now get a modification time set.

---

Posted at 2019-03-05 by TomWS

Well your changes were a 'bit' cleaner than the ones I made last night! I downloaded your files and tested it, fully expecting it to work. However, the result is the same so the date isn't getting from fattime to the SD card. I'll explore today and see what I find.
THANKS for the FAST response! Excellent!
BTW, I also changed my board settings to include 3 SPI as supported by the nRF52832 (and as needed by my project board). The MDBT42Q has set only 1 SPI. I'm using more than one because, in the past, I've found that SD cards can get 'cranky' about sharing SPI bus and also, for route-ability on my board, it was easier to wire 3 independent SPI to the 4 SPI devices I have.

I'll let you know what I find on setting the date code.
Thanks again, Tom

---

Posted at 2019-03-05 by TomWS

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.

---

Posted at 2019-03-05 by TomWS

Just to complete the story, changing baudrate helps up to 1MHz, but it's diminshing returns after that. Maybe for larger blocks the knee would move out more.

---

Attachments:

• SPIwriteTimevsBaud.jpg

---

Posted at 2019-03-05 by @gfwilliams

Not working

Did you try an official build, or it was just what you built yourself? If you didn't make clean that'd have caused all kinds of issues.

But basically what I've done sets the creation time just fine, it just doesn't touch the modified time?

fs.statSync

I haven't heard of many people using it, but the current behaviour wasn't intentional - could you send a PR? :)

3 SPI as supported by the nRF52832

Does it work ok? I was pretty sure that the SPI and I2C hardware was shared, so you couldn't use both at the same time (hence me only exposing one of each rather than trying to check which one was in use).

https://infocenter.nordicsemi.com/pdf/nRF52832_PS_v1.3.pdf section 15.2 - Peripherals with shared ID

Realistically software SPI's pretty speedy though, and since the MCU is just sitting there waiting for the hardware to finish you're not saving a bunch of time by using hardware.

1MHz

100kHz default is because SPI has to talk to lots of stuff. Generally most people start off wiring stuff to Espruino with long wires or a breadboard (or both) and then even 1MHz is pushing it - and it's obviously bad news if comms to the SD card is unreliable.

On the original Espruino board (the only one with an SD socket on board) we run it at 4MHz. You'll probably find that with larger writes the higher baud rate really does pay off.

---

Posted at 2019-03-05 by TomWS

Did you try an official build, or it was just what you built yourself? If you didn't make clean that'd have caused all kinds of issues.

But basically what I've done sets the creation time just fine, it just doesn't touch the modified time?

I was lazy and, since I had just built everything else, did a make and saw that fattime.c had been compiled. It was only after I changed ff.c and rebuilt, again not 'clean', that the behavior worked. Whether or not it would have worked without the change to ff.c and done a clean build, I'm afraid, I don't know. I'd have to remove the change to ff.c and rebuild it to know for sure whether that change was necessary.

Um, no, setting SPI to 3 did nothing useful other than remove the error when I tried to setup SPI2. No error, but also no joy as there was no SPI activity using SPI2 instance. If I simply changed the code to use SPI1, but the same pins, everything worked except when I tried to use D09 as a CSpin - that didn't work. In my Board file I had commented out the NFC section that defines the NFC pins, but apparently the HW still configures them. I had to move to pin D11 for the CSpin.

It makes sense that larger blocks would benefit from faster SPI, but I'm not there yet. 1MHz is ok for now. I can't use software SPI since theoretically I'll have concurrent SPI operations, but I have a feeling that, with this environment, I may be pushing the envelope a bit too much to achieve that.

I haven't heard of many people using it, but the current behaviour wasn't intentional - could you send a PR? :)

Sure, what's a 'PR'? :-)

---

Posted at 2019-03-05 by TomWS

Hmmmm, wading deep into jshardware.c and I see that there is a bit of work to do to enable multiple SPI instances...
I think I'll save that for another day and just do individual device testing for the moment.

Re NFC pins, I noticed that I failed to comment out:
'DEFINES+=-DHAL_NFC_ENGINEERING_BC_FTPAN_WORKAROUND=1',
in the BOARD file. I'll rebuild and try pin D09 again.

---

Posted at 2019-03-05 by TomWS

Re NFC pins, I noticed that I failed to comment out:
'DEFINES+=-DHAL_NFC_ENGINEERING_BC_FTPAN­_WORKAROUND=1',
in the BOARD file. I'll rebuild and try pin D09 again.

Well, that wasn't sufficient, however, adding:

'DEFINES+=-DCONFIG_NFCT_PINS_AS_GPIOS', # disable NFC pins to enable as GPIO

Did work. D09 and D10 are now freed up to be used as GPIO!

---

Posted at 2019-03-05 by Wilberforce

Sure, what's a 'PR'? :-)

Pull request in GitHub.

---

Posted at 2019-03-06 by TomWS

PR done (I think)...
Turns out the month was reported incorrectly by statSync as well. This new version fixes time report to localtime and the correct month.

---

Posted at 2019-03-06 by @gfwilliams

Thanks!

---

Posted at 2019-03-06 by TomWS

You're welcome!

I forgot to mention that your previous update to fattime.c, etc, was ok. It was my 'non-clean' build that kept it from updating (due the .h file that was also changed). The additional setting modification time during create (see #4) was not necessary UNLESS you did a fs.statSync immediately after opening a newly created file. Once the file was closed, the mod dates were updated properly.

---

Posted at 2019-03-07 by @gfwilliams

Ahh, thanks - that's good to know! I thought it was strange that the FatFS library didn't update modified time properly.

I guess it makes sense - if you have the file open for a while you want to write the modified time to the time of the last write rather than when the file was opened.