• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 479 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

EK-TM4C129EXL: ghost values while loggin to sd card

Manzi Nizeyimana
Prodigy 30 points
Part Number: EK-TM4C129EXL

Hello everybody?

I am making a data logger where i store ma values from my accelerosensor( X,Y and Z)  to a sd card. 

I already solved some issues, but now i have a issue with ghost value. When i read de data that are stored in the SD card, they dont match with the real data and random number are added to it. 

I should have values between 0 and 2000. but sometimes I even got values of 110000. Could someone help me with this please? 

Also It does not print in a new line after the 3 values are printen. I tought "\r\n" was the correct syntax? 

#define TARGET_IS_TM4C129_RA1
#include <stdint.h>
#include <stdbool.h>
#include <string.h>
#include <stdio.h>
#include "inc/hw_memmap.h"
#include "inc/hw_types.h"
#include "driverlib/gpio.h"
#include "driverlib/rom.h"
#include "driverlib/rom_map.h"
#include "driverlib/ssi.h"
#include "driverlib/sysctl.h"
#include "driverlib/systick.h"
#include "driverlib/pin_map.h"
#include "driverlib/adc.h"
#include "diskio.h"
#include "ff.h"
#include "ffconf.h"
#include "driverlib/fpu.h"
#include "stdlib.h"



volatile uint32_t g_ui32SysClock;

 static FATFS g_sFatFs; // The following are data structures used by FatFs.
 static FIL fil;
 FRESULT iFResult;

 uint32_t value[3];
 volatile uint32_t valueX;
 volatile uint32_t valueY;
 volatile uint32_t valueZ;
 char strValue[10];


 uint32_t count = 8*1024;
 uint32_t counter=0;



int main(void)
{

    FPULazyStackingEnable(); // enables floating point
    g_ui32SysClock= SysCtlClockFreqSet((SYSCTL_XTAL_25MHZ | SYSCTL_OSC_MAIN | SYSCTL_USE_PLL | SYSCTL_CFG_VCO_480), 8000);

    SysCtlPeripheralEnable(SYSCTL_PERIPH_ADC0);
    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOE); // enable adc and gpio
    ADCHardwareOversampleConfigure(ADC0_BASE, 64);
    GPIOPinTypeADC(GPIO_PORTE_BASE, GPIO_PIN_1 |GPIO_PIN_2 | GPIO_PIN_3);
    FPUEnable();





      SysTickPeriodSet(g_ui32SysClock / 100);
      SysTickEnable();
      SysTickIntEnable();

      ADCSequenceDisable(ADC0_BASE,1);
      ADCSequenceConfigure(ADC0_BASE, 1, ADC_TRIGGER_PROCESSOR, 0);

      ADCSequenceStepConfigure(ADC0_BASE,1, 0, ADC_CTL_CH0);
      ADCSequenceStepConfigure(ADC0_BASE,1, 1, ADC_CTL_CH1);
      ADCSequenceStepConfigure(ADC0_BASE,1, 2, ADC_CTL_CH2|ADC_CTL_IE| ADC_CTL_END);

      ADCSequenceEnable(ADC0_BASE, 1);




            iFResult = f_mount(0, &g_sFatFs);


           while(1) {
            iFResult = f_open(&fil, "testfile.txt",FA_OPEN_ALWAYS|FA_WRITE);
            iFResult = f_lseek(&fil, f_size(&fil)); // moves the file read/write pointer of an open file object.

            ADCIntClear(ADC0_BASE, 1);
            ADCProcessorTrigger(ADC0_BASE, 1);



                while(!ADCIntStatus(ADC0_BASE, 1, false))
                       {
                       }
                ADCSequenceDataGet(ADC0_BASE, 1,value);
                valueX = value[0];
                valueY = value[1];
                valueZ = value[2];


                iFResult = f_mount(0, &g_sFatFs);
                iFResult = f_open(&fil, "testfile.txt",FA_OPEN_ALWAYS|FA_WRITE);
                iFResult = f_lseek(&fil, f_size(&fil)); // moves the file read/write pointer of an open file object.

                sprintf(strValue,"%d, %d,%d\r\n",valueX,valueY,valueZ);
                iFResult = f_write(&fil, &strValue,4, &count);




                iFResult = f_close(&fil);

           }


               // f_mount(0, NULL);


}

 

  • 0
    Guru 117855 points

    Manzi Nizeyimana said:
    now i have a issue with ghost value.

    My friend - might that 'ghost sighting' prove similar to those of 'Bigfoot?'   

    While your 'ghost' finding (may) be correct - do not these issues (following) deserve (some) commentary:

    • How has it been established - even (has) it ever been established - that the 'Raw Sensor Data' is itself, 'Ghost Free?'
    • Your report includes (only) data stored to the SD card - which enables (either)
      • Raw Sensor Data to be 'ghost laden'
      • Issue or issues w/your transfer of sensor data (both in & out) to the SD card

    Both cases are possible - and may occur together - which suggests that your study/analysis should, 'Recognize & Test for sensed data's correctness.'    No such report of that effort has (yet) arrived.

    As a long-term believer in 'KISS' - would it not prove (beyond) useful - for you to: 'Seed the SD Card w/'Dummy Values' - perhaps sequential in nature - which quickly/easily reveal the success (or not) of your Transfer Mechanism.   (between MCU & SD Card.)   Such appears as a 'useful' first order of business.

    Premature optimization is often noted here - your 'Transfer to/from the SD Card' is 'Job #1' - transfer speed (optimization) should occur (later.)

    Often 'data patterns' are helpful in signaling 'when/where' your transfer 'breaks.'    The data presented here - at least upon quick observation - reveals:

    • Top line data (first 30 data points) reveals 'illegal data' (data > 2000) alternating w/(assumed) legal data.  (0 ≤ data < 2001)   Is not that 'alternation' - of any interest?   (report was silent in that regard)
    • Second & third lines of data appear legal.    Why is that - what had changed?   (those are useful facts - are they not?)
    • Fourth line data reveals '4 clustered illegal values' - remaining appear legal.   Again - what has changed?
    • Your narrative and code indicate your capture of 3 sensor channels.  (X,Y,Z)   Yet - most of the data presented - due to the 'data patterns' - appears to be confined to 'Two Data Channels.'

    Report here should prove of some value/guidance in enabling (your) further analysis.   I'd slow the transfer speed between MCU & SD Card - at least during your initial investigation.   Give your system 'Every chance to succeed' - attempt to 'Break Land Speed records' only later...   (maybe)

  • 0
    TI__Guru 72500 points

    Your string may be too small to contain the three values, commas the \r\n and a null character. You only allocated 10 characters.

  • 0 in reply to Bob Crosby
    Prodigy 30 points

    Hello, 

    I increased the length of my string and it partially solved my issues. My first line is good, but from the second line on, it leaves a few empty spaces and only start printing after the empty spaces. 

    It looks like I coded some empy places after the \r\n. 

    Could you see where i'm wrong in this line ? 

    sprintf(strValue,"%d,%d,%d\r\n",valueX,valueY,valueZ);

  • 0 in reply to Manzi Nizeyimana
    TI__Guru 72500 points

    I don't think the problem is with your sprintf(). In line 100 you have:

                    iFResult = f_write(&fil, &strValue,4, &count);

    The third argument in the call to f_write() is the number of bytes to write. You specified 4. Therefore only the first 4 characters of the string "strValue" will be written. What I think you want is:

                    sprintf(strValue,"%d, %d,%d\r\n",valueX,valueY,valueZ);
                iFResult = f_write(&fil, strValue, strlen(strValue), &count);

  • 0 in reply to Bob Crosby
    Prodigy 30 points

    First of all, thanks a lot for your help! 

    It kinda solved my problem toon but now I have something weird. There is still empty places in the first lines, but after a couples lines it dissapear. 

  • 0 in reply to Manzi Nizeyimana
    TI__Guru 72500 points

    I am not sure why you have the blank or tab characters at the beginning of those lines. Your code is always appending. Could those lines be from a previous attempt? I also see that you call f_mount() outside of the while loop (line 74) and then inside the loop call f_open() (line 78) and f_seek() (line 79). You then call f_mount(), f_open() and f_seek() again (lines 95-97).  I suggest you remove the redundant f_mount(), f_open() and f_seek() (lines 95-97).