• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 31 subscribers
  • Views 928 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.

Device stops relaying data after one loop

Elizabeth Visosky
Prodigy 85 points

I have a TM4C123GXL LaunchPad with an attached BOOSTXL-SENSHUB sensor hub. I am currently modifying the compdcm_mpu9150 example code. I have the most recent version of CCS.

My problem is the following: I am trying to output the data from the sensor hub to a file. I have (mostly) successfully done this with the humidity_sht21 example code, but for some reason the modified compdcm_mpu9150 code just runs through the main while loop once, then stops.

For the humidity code, I had to sufficiently increase the heap and stack size before it would function. I did the same thing here, and then further increased it in hopes that it would resolve the issue. It hasn't.

At this point, I really don't know what else I could try to get this code to function through more than one iteration of the loop.

The code changes are as follows:

  • insert:   #include <stdio.h>, #include <time.h> on lines 25 and 26
  • starting on line 517, insert:   time_t t = time(NULL);

    struct tm tm = *localtime(&t);

    char concat[50];
    snprintf(concat,10,"%d",tm.tm_year-100); //-100 so that it's from 2000, not 1900
    char added[50];
    snprintf(added,10,"%03d",tm.tm_yday+1); //+1 so it's 1-366
    strcat (concat, added);                //should make it 001-366
    snprintf(added,10,"%02d",tm.tm_hour); //ditto for these; 00-60
    strcat (concat, added);
    snprintf(added,10,"%02d",tm.tm_min);
    strcat (concat, added);
    snprintf(added,10,"%02d",tm.tm_sec);
    strcat (concat, added);
    strcat (concat, ".txt"); //Will use concat in fopen command

  • near the bottom of the file, before the UARTprintf statements, insert:    FILE * fid; fid = fopen(concat, a)
  • finally, after each UARTprintf statement, insert: fprintf(fid, "%d.%03d\t%d.%03d\t%d.%03d\t\t", i32IPart[0], i32FPart[0], i32IPart[1], i32FPart[1], i32IPart[2], i32FPart[2]); //where each part[i] is changed appropriately

I understand I've indicated my changes to the code in a fairly muddled way. If it would be better to copy-paste the whole 736 lines of code, let me know.

Thank you in advance.

  • 0
    Guru 47900 points

    Elizabeth Visosky said:
    code just runs through the main while loop once, then stops.

    Really?   Might it prove more likely that your code does NOT correctly navigate thru the entire loop - and hangs (therein) somewhere?

    You're silent as to your test/troubleshooting detailed methods.   Have you (really) confirmed entry into - and exit from - each/every function call w/in your (long) while loop?

    May I suggest that you reduce your code - run maybe just 20% of your loop functions - and note if those functions "escape" your program hang?   If successful - you can repeat that test w/next (small) group of "suspects."   Once you determine the "troublesome function(s)" your correction has far greater focus - thus chance for success...

  • 0 in reply to cb1
    Prodigy 85 points
    Hi cb1-,
    I assumed that, since it managed to execute the fprintf statements (at the end of the code), it was going through all the necessary steps to get there. I'll set up some breakpoints in the code and respond with my results. It probably is just hanging up somewhere, for some reason.
  • 0 in reply to Elizabeth Visosky
    Guru 47900 points
    Assumption minus real "Test/Verify" is unlikely to succeed.

    Systematic backing out of "suspect functions" - followed by loop's ability to persist - (as suggested) is a credible path to success...
  • 0 in reply to cb1
    Prodigy 85 points
    Hi cb1-,

    I believe I have found the source of the hangup. There is another while loop at the beginning of the main while loop. It apparently makes the device "go to sleep mode while waiting for data ready." Since that while loop seemed to be causing issues, I commented it out.

    Now the program writes data to file without encountering that hangup. However, modifying the code it has introduced other problems.
    My primary concern is that the data retrieval functions seem to have stopped executing properly. The first line of data is fine, the second is fine, but the third is identical to the second, as is the fourth, and so on. I've taken data twice (once was for a full 5 minutes), and unless there's a massive coincidence, the data just stops being updated after the second run-through.

    So, I see two ways going about fixing this. Either figure out why ROM_SysCtlSleep() isn't updating g_vui8I2CDoneFlag (so the while loop stops), or figure out why CompDCMMagnetoUpdate and the other update functions stop obtaining new data. Do you have any insight as to what path would be best/ most likely to yield a solution?
  • 0 in reply to Elizabeth Visosky
    Guru 47900 points
    I do - but will take some time/thought to properly consider...

    As big proponents of KISS - cannot you test via, "Incrementing dummy values" in place of your, "Live Data?" This method tests your "Passage of data through your system" due to its use of readily recognizable data. If this succeeds - then you (know) that indeed - your update functions are (somehow) flawed.