next topic »

[on:]

I have a Thermostat control project that is behaving strangely when talking to cosm. It works well for some number of cycles then stops updating. I have inserted print statements and am posting the last good update and the first bad update. In this case the last good update was at cycle 300. The cosm update code looks like this:

Code:

   
  Serial.println("Connecting...");
    if (client.connect(server, 80)) {
      
      client.print("GET /api/");
      client.print(REMOTE_FEED_ID);
      client.print(".csv HTTP/1.1\nHost: pachube.com\nX-PachubeApiKey: ");
      client.print(PACHUBE_API_KEY);
      client.print("\nUser-Agent: Arduino (Pachube In Out v1.1)");
      client.println("\n");

      //Serial.println("finished GET now PUT, to update");

      client.print("PUT /api/");
      client.print(SHARE_FEED_ID);
      client.print(".csv HTTP/1.1\nHost: pachube.com\nX-PachubeApiKey: ");
      client.print(PACHUBE_API_KEY);

      client.print("\nUser-Agent: Arduino (Pachube In Out v1.1)");
      client.print("\nContent-Type: text/csv\nContent-Length: ");
      client.print(content_length);
      client.print("\nConnection: close\n\n");
      client.print(pachube_data);
      client.print("\n");

The output shows a trincation in the "X-PachubeApiKey" line and I can not figure out what would cause this. I have substituted the text "my_key_was_correctly_listed_here" exactly where my key is printing out. I have also highlighted in red the good lines and then the bad lines. Any suggestions would be much appreciated. I have checked for data memory overflow, the sketch indicates 72% at it's start. Something is getting overwritten but I can't find it. If you think this is the problem then any suggestions about how to find it would be appreciated.


reset ethernet
GET /api/getfeed#.csv HTTP/1.1
Host: pachube.com
X-PachubeApiKey: my_key_was_correctly_listed_here
User-Agent: Arduino (Pachube In Out v1.1)

PUT /api/putfeed#.csv HTTP/1.1
Host: pachube.com
X-PachubeApiKey: my_key_was_correctly_listed_here
User-Agent: Arduino (Pachube In Out v1.1)
Content-Type: text/csv
Content-Length: 33
Connection: close

776,610,705,707,703,703,737,300,0
 HTTP/1.1 200 OK
Date: Sun, 10 Jun 2012 02:13:02 GMT
Content-Type: text/plain; charset=utf-8
Connection: keep-alive
Last-Modified: Sat, 09 Jun 2012 05:51:04 GMT
X-Runtime: 32
X-Pachube-Logging-Key: logging.EgdfTlyjwCw1ZweUULUK
Content-Length: 21
X-PachubeRequestId: fcaa00dd573168a3dd0982fc0e08da9272cae065
Set-Cookie: _pachcore_app_session=BAh7BjoPc2Vzc2lvbl9pZCIlMmJiNjhAge: 73313
Cache-Control: max-age=86400
 Accept-Encoding

--- updated:
776,610,705,707,703,703,737,300,0
--- retrieved:
0 0 0 0 0 1 0 0 0 0 1  
0Date: Sun, 10 Jun 2012 02:13:02 GMT
Content-Type: text/plain; charset=utf-8
Connection: close
X-PachubePurgeCache: t:feeds/5744
X-Runtime: 101
Content-Length: 1
X-Pachube-Logging-Key: logging.EgdfTlyjwCw1ZweUULUK
X-PachubeRequestId: e89959ce93cec852e627f538b24adb8fdd830884
Set-Cookie: _pachcore_app_session=BAh7BjoPc2Vzc2lvbl9pZCIlMjY0YzA5


Cache-Control: max-age=0
 Accept-Encoding

reset ethernet
GET /api/getfeed#.csv HTTP/1.1
Host: pachube.com
Xmy_key_was_correctly_listed_here
User-Agent: Arduino (Pachube In Out v1.1)

PUT /api/putfeed#.csv HTTP/1.1
Host: pachube.com
Xmy_key_was_correctly_listed_here
User-Agent: Arduino (Pachube In Out v1.1)
Content-Type: text/csv
Content-Length: 33
Connection: close

776,609,705,707,703,703,737,301,0
 HTTP/1.1 401 Unauthorized
Date: Sun, 10 Jun 2012 02:13:49 GMT
Content-Type: text/plain; charset=utf-8
Connection: keep-alive
WWW-Authenticate: Basic realm="Web Password"
Content-Length: 50
Set-Cookie: _pachcore_app_session=BAh7BjoPc2Vzc2lvbl9pZCIlN2I0YWNCache-Control: no-cache

You do not have permission to access this resourceHTTP/1.1 401 UnDate: Sun, 10 Jun 2012 02:13:49 GMT
Content-Type: text/plain; charset=utf-8
Connection: close
WWW-Authenticate: Basic realm="Web Password"
Content-Length: 50
Set-Cookie: _pachcore_app_session=BAh7BjoPc2Vzc2lvbl9pZCIlNThlOTUCache-Control: no-cache

[Reply #1 on:]

Is there more code than this?

Is there some timing or delay?

[Reply #2 on:]

Yes there is much more code for reading 7 onewire sensors, checking they read correctly, converting the values, turning on relays, turning off relays, etc. I did not want to post it all here because it is long and not very relevant to this problem.
I use delays when reading the onewire sensors but not in this piece of code. Are they needed?

[Reply #3 on:]

Yes there is much more code for reading 7 onewire sensors, checking they read correctly, converting the values, turning on relays, turning off relays, etc. I did not want to post it all here because it is long and not very relevant to this problem.
I use delays when reading the onewire sensors but not in this piece of code. Are they needed?

I suggest that you copy your sketch and cut out everything except the bare minimum necessary to demonstrate the problem.

Firstly, this means that anyone trying to help you can focus on the problem and not have to wade through pages of code that may or may not be relevant.

Secondly, the act of trying to reproduce the problem in a minimal environment may expose assumptions that you've made about what exactly causes the problem, and may enable you to make progress on the problem yourself. 'Divide and conquer' is a very effective troubleshooting technique when you aren't clear what is going on.

[Reply #4 on:]

Your approach makes good sense. Unfortunately this problem seems to depend on changes to code size and where I put some of the strings and variables. That is to say making the changes you suggest changes the nature of the bug so it is hard to pin down. The behavior is that of overwriting the buffer, stack, heap or code. I have used the avr tools to see if this is happening but that does not seem to be the problem.
I will continue to try to isolate the problem and agree that this exercise will be very instructive. Just looking for any additional eyes that may see something obvious I missed.

[Reply #5 on:]

If the problem varies with code size, you may be running out of memory, probably RAM. You are using a lot of string literals. Try putting them in progmem using the F() macro.

[Reply #6 on:]

Unfortunately this problem seems to depend on changes to code size and where I put some of the strings and variables. That is to say making the changes you suggest changes the nature of the bug so it is hard to pin down.

Well, that's a major clue. You've immediately told us that we'd probably be wasting our time looking for logic faults in your code and need to be looking for out-of-memory type problems.

Have you looked at the amount of free RAM in your system after before/during/after startup? There's a popular code fragment posted on the forum which shows you how to measure it.

[Reply #7 on:]

Thank you for the suggestions. I have been removing the string literals - mostly debug statements - but have not yet tried putting the required strings in flash. This should fix the "X-PachubeApiKey: " truncation problem at a minimum. Since I am only using 21K for the program that makes good sence.
On the tools for figuring out SRAM overflow I have used avr-size but it only shows about 71% use. I assume this does not include the stack. Is there a better tool?

[Reply #8 on:]

Here is the code I use to find the free memory at runtime:

Code:

// Find out how much free memory we have
unsigned int getFreeMemory()
{
  unsigned char* temp = (unsigned char*)malloc(16);    // assumes there are no free holes so this is allocated at the end
  unsigned int rslt = (unsigned char*)SP - temp;
  free(temp);
  return rslt;
}

It assumes that you are not using the String class, or anything else that allocates dynamic memory (which is generally a bad idea in embedded systems, see http://critical.eschertech.com/2010/07/30/dynamic-memory-allocation-in-critical-embedded-systems/ for why).

The other approach I have seen used is to call malloc and then free in a loop with gradually increasing allocation size, until it returns null. The size of the last successful allocation is the amount of free memory.