4

I have a sketch that runs on an Arduino Ethernet (that comes with an SD card reader and, of course, an Ethernet interface).

There is a unique place in this sketch where I write to a file on the SD card, which basically looks like this:

char dpath[13]; // File path
char logline[30]; // String to be stored in

/* ... */

File dataFile;
if (dataFile = SD.open(dpath, FILE_WRITE)) {
    dataFile.println(logline);
}
dataFile.close();

I didn't experience any problem for a few months having a couple of Arduinos running this sketch.

Recently, I put to work another one that is behaving weirdly. In particular, I see that on the SD card it generated a somewhat corrupted file.

The file size appears to be 4.0 GB, altough the total size of the SD card is 3.7 GB, and if I try to read it with a hex editor it appears empty:

$ du -h 20130206.DAT_ 
4,0G    20130206.DAT_

$ df -h
Filesystem   Size  Used  Avail  Use%   Mounted on
/dev/sdb1    3,7G   58M   3,6G    2%   /media/B045-FE58

$ hexdump 20130206.DAT_ 
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
fd000000

What could be happening to the microcontroller?

I'm asking this here, because I can't notice any programming problems, and the sketch is running fine on other boards. Should I be aware of some electric known problems? Could for example a not-stabilized power supply or some electromagnetic radiation be leading to this behaviour? I would appreciate any suggestion about electronic issues I should check.

Peter Mortensen
  • 1,676
  • 3
  • 17
  • 23
etuardu
  • 397
  • 3
  • 7
  • 14
  • If your program is running fine on other boards, the it sounds like you have busted hardware. However, you are telling us about high level symptoms a long way from the hardware, so there is little that can be said except "Yup, something seems to be broken". – Olin Lathrop Feb 11 '13 at 16:58
  • I think you might be going over the erase/write cycles of your SD card. You need to look as to how often you are writing data to your SD and if your libraries implement any wear leveling – Kvegaoro Feb 11 '13 at 17:12
  • I write a single line (approx 16 bytes) each 15 minutes – etuardu Feb 11 '13 at 17:28
  • 2
    Exchange SD cards with a known working combination and check where the problem occurs. Does it stay with the Arduino or does it stay with the SD card. Can you reproduce the problem when you do a clean SD card format? Did you test the SD card for errors when formatting it? `mkfs.vfat -c` – jippie Feb 12 '13 at 18:59
  • 3
    By the way, a "sketch" is called a "program" in the real world. It's a good idea to learn how to speak to others outside the arduino coccoon when you want information outside the arduino coccoon. – Olin Lathrop Feb 13 '13 at 21:08
  • @jippie Thanks, in fact I replaced the whole board/SD card/power supply with ones that I tested to be working and I'm experiencing the same problem. I'm starting to think that the bad writings on the SD card are just side effects of the MCU "going mad", maybe because of high-current circuits in the nearby. – etuardu Feb 14 '13 at 08:28
  • 1
    @OlinLathrop Thank you. I would have called it "firmware" but I thought to use the word "sketch" to mean that I used Arduino's libraries. I thought that if someone knows what an Arduino is he would also know the meaning of "sketch". – etuardu Feb 14 '13 at 08:37
  • "Nearby high-current circuits" sounds like the sort of thing that could cause problems, especially if you have e.g. relay arcing going on. Could you elaborate? – pjc50 Feb 14 '13 at 11:43
  • @pjc50 The board is hanged near an AC to DC inverter, inside a metal cabin. It is enclosed in an abs case. There is also a wire that goes from a MCU pin to the outside in order to read inputs. – etuardu Feb 15 '13 at 09:14

1 Answers1

2

Both the SD-card interface and the WizNet interface share the same SPI interface of the microcontroller. There is a known bug (or rather a terrible design neglect) in the Arduino SPI software library in this regard, occasionally causing data corruption. It's not interrupt-safe. The issue is explained and fixed here:

http://www.dorkbotpdx.org/blog/paul/spi_transactions_in_arduino

It accomplishes this by allowing the library user to enclose access to SPI with guard methods:

In a nutshell, SPI.beginTransaction() protects your SPI access from other interrupt-based libraries, and guarantees correct setting while you use the SPI bus.

Oh, the depth of the issue means you have to fix/rewrite everything that takes advantage of the SPI library. Arduino use-case has evolved upwards in complexity from very simple projects, and libraries might take a while to fully reflect this transition.

Siana
  • 414
  • 3
  • 7
  • Incidentally the SPI Transaction API is *actually* getting adopted in 1.0.6 and 1.5.8 of Arduino. It's hopefully going to solve many "mysterious" problems. – vicatcu Nov 12 '14 at 19:26