[Solved] PVER Mismatch with MY_DEBUG

[d4rkr3b3l]

I've searched the forums a bit but haven't been able to find much. I have a sensor node that is starting to act up. It runs normal with out any issues when I have MY_DEBUG commented out. If I un-comment it, to show the debug data, I'm getting a PVER mismatch error and it halts the program from running. I get this error and nothing else... the rest of my code does not run.

Starting sensor (RNNNA-, 2.0.0)
TSM:INIT
TSM:RADIO:OK
TSP:ASSIGNID:OK (ID=1)
TSM:FPAR
TSP:MSG:SEND 1-1-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSP:MSG:READ 0-0-1 s=255,c=3,t=8,pt=1,l=1,sg=0:0
!TSP:MSG:PVER mismatch

This is all I get on my debug window.

All I've been able to find regarding PVER mismatch indicates a protocol issue. I've restarted my node as well as the gateway on several instances... I've also tried re-flashing my sensor node a few times with debug on and off.

Any help that you guys can provide would be great. I'd like to be able to run my program with the debug data on.

Additional Info:

• Running a Pro-Mini @ 8MHz @ 3.3v
• NRF24L01+
• Radio has a dedicated voltage regulator with 10uF on the radio power input
• Sketch without debug enabled uses 88% of dynamic memory
• Sketch with debug enabled uses 91% of dynamic memory
• My sketch includes the following librarys (GOFi2cOLED seems to be the memory hog)

#include <SPI.h>
#include <MySensors.h>  
#include <Bounce2.h>
#include <TimeLib.h>
#include <TimerOne.h>
#include <Wire.h>
#include <GOFi2cOLED.h>

[AWI]

@d4rkr3b3l a good possibility is that you are out of ram memory. This is used for all variables (heap) and the stack. Especially if you are using large buffers you eat it very fast. The percentages mentioned by the compiler only give an indication. There is only little in the Arduino. Without debug you are probably on the edge. > 70% for dynamic is already high.
Time for some code optimization ;-)

[d4rkr3b3l]

I think my code is pretty well optimized. Short of using PROGMEM for my strings I'm not sure what else to do. As soon as I start using the OLED library, memory usage jumps by about 50%. I think I'll need to look into using a different i2cOLED library, or modify the one that I'm trying to use.

Thanks for the input!

[d4rkr3b3l]

Just as an update to anyone that may be interested... My issue was in fact due to RAM usage. I switched from using the GOFi2cOLED library to the u8glib library to drive my OLED display and my ram usage dropped from 91% to 45%. Most OLED libraries (including ADAFRUIT which is the base code for GOFi2cOLED) are going to store the display buffer in ram which makes them a memory hog. Using a 128x64 display means you will consume 8192 bytes just for the display buffer @ 1 byte per pixel, add on top of that all the operational code. The u8glib "pages" the display buffer meaning it can essentially make the buffer as small as you need at the cost of slowing down the refresh rate. For just plain text its not an issue and the paging is not visible on the screen.