Avatar for dprime

dprime

Member since Feb 2014 • Last active Apr 2019
  • 2 conversations
  • 12 comments

Most recent activity

  • in JavaScript
    Avatar for dprime

    Hi Gordon,

    I've doing a full format (FAT32) to the cards between each test to ensure they start off in a known state. I just ran the test overnight, setting the SPI speed to a lower bit rate after the initial write as you suggested. The problem is still there and I have more of an idea of how often it occurs...

    The results:

    • Log entries made 6944
    • 7 bursts of DISK_ERR
    • 92 lines missing from log

    That means bursts of errors happen about every 1000 writes and on average every 72 writes.

    Although I have several SD cards, they're only one type (Kingston, 8GB, Class4).

    Is there anyone who has a different type of card that could run the test listed in post number 4?

    You will need to run the test for at least a couple of hours to be reasonably sure of encountering the problem.

  • in JavaScript
    Avatar for dprime

    My second Espruino arrived on Friday, so I've had a chance to do some more testing. I see this problem on two different Espruino's and two SDcards (although both SDcards are the same make , Kingston 8GB).

    If I run the following test program which simulates the type of logging I've been doing:

    var fs = require('fs');
    var testName    = "TEST152B.LOG";
    var testDetails = "Some text";
    var logInterval = 5000;
    var logEntry    = 0;
    
    // Initialise log file here with header information
    console.log(testDetails);
    fs.appendFileSync(testName, testDetails);
    
    // Function to log some data every so often
    setInterval(function(){
        // Indicate each time function is executed 
        digitalPulse(LED1, 1, 100);
        
        // Log some data.
        logEntry++;
        var logString = logEntry + ": 0123456789 ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz : Time = " + getTime() + "\r\n";
        console.log(logString);
        fs.appendFileSync(testName, logString);
    }, logInterval);    
    

    On Espruino running v1.50, I see the occasional INT_ERR, often two in a row on average 1 in every 100 writes. The log file on the SD card is missing the line logged:

    From console log:
    383: 0123456789 ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz : Time = 2239.606450000000222644
    ERROR: Unable to write file : INT_ERR
    384: 0123456789 ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz : Time = 2244.606450000000222644
    ERROR: Unable to write file : INT_ERR
    

    On Espruino v1.52, the errors are still there but the error type and pattern has changed. Now I see bursts of around 10 consecutive DISK_ERR. Again, the log file on the SD card is missing the lines logged:

    From console log:
    >1749: 0123456789 ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz : Time = 8814.510775683593237772
    ERROR: Unable to write file : DISK_ERR
    >1750: 0123456789 ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz : Time = 8859.444492382812313735
    ERROR: Unable to write file : DISK_ERR
    >... More consecutive DISK_ERR
    >1760: 0123456789 ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz : Time = 9122.928319238280892022
    ERROR: Unable to write file : DISK_ERR
    >1761: 0123456789 ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz : Time = 9135.649541601562305004
    

    I think the problem seems to be a little worse when I run PWM outputs, onewire temperature probes and serial output. I did wonder if the problem is related to electrical noise or maybe a problem with interrupts.

  • in JavaScript
    Avatar for dprime

    At the moment I'm using the Espruino to do some long term logging tests, using the serial port rather than the SD card.
    I'll try using the latest code when I've finished my tests, probably next weekend.
    I'm going to have to order some more of these Espruinos...
    Thanks

  • in JavaScript
    Avatar for dprime

    ok, thanks.
    I'll test it when the next firmware level is available.

  • in JavaScript
    Avatar for dprime

    I'm writing some code to do some logging of data to the SD card and am seeing occasional errors when calling appendFileSync(), 2 writes out of 160 in a recent run.

    The error is: "ERROR: Unable to write file : INT_ERR"

    The appendFileSync() doesn't return a value to tell me programatically whether the operation succeeded or not. Is there any other way to tell if appendFileSync() encountered an error?

  • in JavaScript
    Avatar for dprime

    Thanks Gordon.

    I can work around the problem for now by poking the output config back to open-drain each time I change the PWM as I'm not doing it often at the moment and the short push-pull spike can be filtered out.

    I'm really impressed with how easy the board and SW is to use. Great for prototyping and testing various hardware ideas out.

    David

  • in JavaScript
    Avatar for dprime

    Yes it works but analogWrite() function is overwriting the output type (CNF0 which defines push-pull or open-drain) back to push-pull each time.
    It is also setting CNF1 to change from general purpose output to Alternate function output, which I assume is to attach the timer to the output port.

    Using pinMode() to set pin A0 to output mode first, the code below shows this behaviour:

    pinMode(A0, "output");
    console.log("Peek 0x40010800:", peek32(0x40010800));
    poke32(0x40010800, (peek32(0x40010800) & (~0b1100)) | 0b0100); // mask out existing bits and set open drain
    console.log("Peek 0x40010800:", peek32(0x40010800));
    analogWrite(A0, 0.5, { freq : 100 } );
    console.log("Peek 0x40010800:", peek32(0x40010800));
    

    Output, comments added manually:

    Peek 0x40010800: 3   // 0b0011 - pinMode(...) sets push-pull, normal pin function
    Peek 0x40010800: 7   // 0b0111 - poke32(...) Set to open drain
    Peek 0x40010800: 11  // 0b1011 - analogWrite(...) sets back to push-pull output, alternate pin function
    
  • in JavaScript
    Avatar for dprime

    Having a bad 5 minutes...

    Please ignore previous post.
    In post 3 above on Line 4 of the first code example, I originally set the output to 0b0100 not 0b1100 which was your original suggestion. Same result as far as PWM open-drain output is concerned.

Actions