Periodically, a new line will overwrite a previous entry. The only discernable pattern is that the overwrite is always on a line exactly 10 iterations previous. It normally happens on an order of every 100 iterations. This is on an msp430f1611.
Example below:
- Code: Select all
Iterations: 0000000037 Current ticks: 0000003832.
Iterations: 0000000038 Current ticks: 0000003932.
Iterations: 0000000039 Current ticks: 0000004032.
Iterations: 0000000040 Current ticks: 0000004132.
IteratioIterations: 0000000051 Current ticks: 0000005232.
ns: 0000000042 Current ticks: 0000004332.
Iterations: 0000000043 Current ticks: 0000004432.
Iterations: 0000000044 Current ticks: 0000004532.
Iterations: 0000000045 Current ticks: 0000004632.
Iterations: 0000000046 Current ticks: 0000004732.
Iterations: 0000000047 Current ticks: 0000004832.
Iterations: 0000000048 Current ticks: 0000004932.
Iterations: 0000000049 Current ticks: 0000005032.
Iterations: 0000000050 Current ticks: 0000005132.
Iterations: 0000000052 Current ticks: 0000005332.
Iterations: 0000000053 Current ticks: 0000005432.
Iterations: 0000000054 Current ticks: 0000005532.
Iterations: 0000000055 Current ticks: 0000005632.
Iterations: 0000000056 Current ticks: 0000005732.
....
Iterations: 0000000165 Current ticks: 0000016632.
Iterations: 0000000166 Current ticks: 0000016732.
Iterations: 0000000167 Current ticks: 0000016832.
Iterations: 0000000168 Current ticks: 0000016932.
IteratioIterations: 0000000179 Current ticks: 0000018033.
ns: 0000000170 Current ticks: 0000017132.
Iterations: 0000000171 Current ticks: 0000017232.
Iterations: 0000000172 Current ticks: 0000017332.
Iterations: 0000000173 Current ticks: 0000017432.
Iterations: 0000000174 Current ticks: 0000017532.
Iterations: 0000000175 Current ticks: 0000017632.
Iterations: 0000000176 Current ticks: 0000017732.
Iterations: 0000000177 Current ticks: 0000017832.
Iterations: 0000000178 Current ticks: 0000017932.
Iterations: 0000000180 Current ticks: 0000018132.
Iterations: 0000000181 Current ticks: 0000018232.
Iterations: 0000000182 Current ticks: 0000018332.
Iterations: 0000000183 Current ticks: 0000018432.
In a debugging effort I modified the bulk of task_sd_append.c to make sure the buffer doesn't overrun, file is properly closed, the file seeks to the end, and that the file position is always greater than the last appendage (I put breakpoints on these, but they're never triggered.) I've tried effs_thin 1-3.
- Code: Select all
// Attempt to open the file, in append mode.
file = f_open(STR_FILE_NAME, "a+");
// If successful, append a new line to the file and report to user.
if (file) {
f_seek ( file , 0 , SEEK_END );
file_pos_old = file_pos;
file_pos = f_tell(file);
if(file_pos < file_pos_old)
_NOP();
// Place banner at start of each new run.
if (count_appends == 0)
sprintf(strTmp, STR_CRLF STR_APP_NAME STR_CRLF STR_VERSION STR_CRLF STR_TO_APPEND, count_appends, OSGetTicks());
// Always log counter and current ticks.
else {
sprintf(strTmp, STR_TO_APPEND, count_appends, OSGetTicks());
}
if (length = f_write(strTmp, 1, strlen(strTmp), file)) {
sprintf(strTmp, STR_TASK_SD_APPEND "Appended %d bytes to " STR_FILE_NAME ".", length);
if(length != 0x34)
_NOP();
//user_debug_msg(strTmp);
count_appends++;
}
else {
errors++;
sprintf(strTmp,"error");
//user_debug_msg(STR_TASK_SD_APPEND "f_write failed to write to " STR_FILE_NAME ".");
}
f_close(file);
}
// O/wise flag as an error.
else {
errors++;
// user_debug_msg(STR_TASK_SD_APPEND "Cannot open " STR_FILE_NAME ".");
}
Anyone with idea's or suggestions?