Is this a memory leak?

Projects Programming
1

Hi all,

I am using a home brew atmega1284p based arduino running on MightyCore.
I am experiencing a "strange" behavior which in my limited programming epxerience points to some sort of memory leak.
See below output on Serial monitor in two cases :frowning:

h - hel5         <-------
s - System status
q - settings
r - Read acquisition data



Firmware: v1.0
PCB Ver : 1
Free RAM   : 14857
Ambient Tmp: 22.5 C
Set Temp   : 320 C
Temp0      : 25.0 C
Temp1      : 783.0 C
Raw0       : 6.0 C
Raw1       : 745.0 C
Vin        : 0 ⸮⸮5    <----------

In the above two cases output appears corrupted in two cases as shown with the arrows.

Trying to isolate the root of the problem I disabled various functions of the sketch in turn and I narrowed down the source in the following function which when disabled, the problem disappears:

uint16_t denoiseAnalog (byte port) {
   
  uint16_t result = 0;
  ADCSRA |= bit (ADEN) | bit (ADIF);    // enable ADC, turn off any pending interrupt
  if (port >= A0) port -= A0;           // set port and
  ADMUX = (0x0F & port) | bit(REFS0);   // reference to AVcc 
  set_sleep_mode (SLEEP_MODE_ADC);      // sleep during sample for noise reduction

  for (byte i=0; i<32; i++) {        // get 32 readings

   sleep_mode();                       // go to sleep while taking ADC sample
    while (bitRead(ADCSRA, ADSC));      // make sure sampling is completed
    result += ADC;                      // add them up
  }
 sleep_disable();
 
  bitClear (ADCSRA, ADEN);              // disable ADC
  return (result >> 5);                 // devide by 32 and return value
}

Further investigation indicated that commenting out the sleep_mode(); command also makes the problem go away!

Note that the sketch makes use of the following libraries:

#include <U8glib.h>             // https://github.com/olikraus/u8glib
#include <PID_v1.h>             // https://github.com/wagiminator/ATmega-Soldering-Station/blob/master/software/libraries/Arduino-PID-Library.zip 
                                // (old cpp version of https://github.com/mblythe86/C-PID-Library/tree/master/PID_v1)
#include <EEPROM.h>             // for storing user settings into EEPROM
#include <avr/sleep.h>          // for sleeping during ADC sampling
#include <OneWire.h>
#include <DallasTemperature.h>

I wasn't able to investigate any further.
Can anybody point me to the right direction?

2

0 is a count of 1, 32 is a count of 33 which exceeds the bounds of the array. Can't tell because I cannot see where the array is declared and that is why CODE SNIPPETS SUCK.

3

Hi and thanks for your reply.

Firstly, unless i am missing something, from 0 to 31 (ie <32) is a total of 32 iteration steps, not 33
and then, there is no array here. It just takes 32 samples and takes the average.

I could post the whole sketch if you like but i wouldnt think anyone spend the time going through it..

4

Once again bitten by a code snippet. Good luck.

5

Thanks for your kind wishes!

6

where are you printing? is the serial interface fully back up when you try to print?

7

What do you mean by that?
I am printing on the Serial monitor connected via FTDI TTL to USB module.
Same module I am using to upload the sketches

8

I'm just wondering if the UART wakes up instantly from sleep (and where is the code doing the printing. (Snippets R Us!)

9

Obvious question, are you putting the processor to sleep while serial data is being sent?

10

yes, good point. a flush would help after the printing is done

11

I suspect your homebrew has enough stray capacitance that the 16MHz is off. You did not indicate the BAUD of the serial mo itor, but slow things down below 9600 and see if the output improves.

12

Thanks for your replies.
No. Printing is done after the ADC sampling is complete and the processor wakes up.

13

I am using 9600 bps . Lowering or increasing the baud rate of the similar monitor has no some effect.:
Lowering the baud rate to 4800, the corrupted pattern appears in different parts of the output
ie :frowning:

h - hel5
s - System status
q - settings
r - U⸮⸮⸮????sdaquisition data

14

OK

do you go back to sleep right after?

15

The processors go to sleep only during the ADC sampling ie during that "for loop" in the snippet above. That gets executed periodically once in every main loop run.
The terminal output only happens when i press button.

16

if you add a Serial.flush() after all the printing, does it change anything?

at 9600 bauds you print 960bytes a second so printing ~260 bytes like this

h - hel5
s - System status
q - settings
r - Read acquisition data



Firmware: v1.0
PCB Ver : 1
Free RAM   : 14857
Ambient Tmp: 22.5 C
Set Temp   : 320 C
Temp0      : 25.0 C
Temp1      : 783.0 C
Raw0       : 6.0 C
Raw1       : 745.0 C
Vin        : 0 ⸮⸮5

takes ~271ms... the buffer will be full, so there will be a pause but the code will continue when you have 64 bytes left so 66ms of printing still due... if there is a chance for you to go back to the top of the loop and sleep, you'll be in trouble

do you handle the button as an interrupt or just by polling in the loop?

that's where having a real code would save time.... snippets don't work..

1 Like
17

YES!
I had to add a flush() after every printing statement and it seemed to do the trick.
Thanks so much for helping me get this fixed.
Apologies for not uploading the whole code but ,as explained i tried to isolate the problem before addressing the forum to save time.
Next time I will do both!

18

you don't need it after every print, just when you are done with the printing sequence (if you have multiple prints)

PS: that's what @david_2018 was hinting in his post

19

Yes sorry, that's what I meant.

20

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.