SoftwareSerial stops working... baffled !!

If I compile your code, I get a number of warnings (I have warnings turned up to the max) that you should probably address. Although your free memory seems constant, I would also get rid of all the Strings in the sketch too.

I’m not convinced that those things will resolve your issue, but I’d be more inclined to dig into a version of the code that is cleaner.

wildbill:
If I compile your code, I get a number of warnings (I have warnings turned up to the max) that you should probably address. Although your free memory seems constant, I would also get rid of all the Strings in the sketch too.

I'm not convinced that those things will resolve your issue, but I'd be more inclined to dig into a version of the code that is cleaner.

I have been playing, and if I comment out the call to RemoteXY_Handler() I can un-comment all my code, and pin 12 remains clean.

So it seems that RemoteXY_Handler is eating my free memory at a huge alarming rate, and my numbers indicate it is grabbing 1060 bytes (+/-1).

The Strings go to RemoteXY, it's the only way to get dynamic text onto the screens.

I'm going to open up the include files and see if I can find out why, but I'm no expert, and don't really know what to look for.

Unfortunately, the developer of RemoteXY appears to have "lost interest", doesn't respond to users' requests for help, and is making no attempts to do any development or debugging on this system, hasn't posted in his own forum since April, while still collecting license fees.....

If anyone else would like to have a look, the library is available from here

wildbill - I have addressed all the warnings as you suggested, there aren’t any now issued for any of my code, there’s one from EEPROM, but the majority are from RemoteXY.

The attached version runs fine without the call to RemoteXY_Handler();, pin 12 clean as a whistle…

SoftSerialTest.ino (21.2 KB)

I think I see your mistake. Hint: A7 is NOT a digital pin.

johnwasser:
I think I see your mistake. Hint: A7 is NOT a digital pin.

O M G !

Yes, I had that pinMode assignment....

But what a strange way to tell me about it - killing the SoftwareSerial when the sketch gets too big !!!

Lesson learned, and WELL SPOTTED - thanks.

Looks like everything is normal again.

daba:
But what a strange way to tell me about it - killing the SoftwareSerial when the sketch gets too big !!!

A7 == 21 and that goes off the end of the digital_pin_to_port_PGM and digital_pin_to_bit_mask_PGM arrays. The two arrays are consecutive in FLASH so when you go to element 21 of a 20-element digital_pin_to_port_PGM array you get to element 1 of the digital_pin_to_bit_mask_PGM array: _BV(1). Bit 1 has the value 2 and the value 2 means Port B. I don't know what is in element 21 of the 20-element digital_pin_to_bit_mask_PGM array in FLASH but any bits set to 1 will set the corresponding bits in DDRB to 0, making them INPUT. It must be a byte with bit 4 set to 1 since Pin 12 is Port B, bit 4.

johnwasser:
A7 == 21 and that goes off the end of the digital_pin_to_port_PGM and digital_pin_to_bit_mask_PGM arrays. The two arrays are consecutive in FLASH so when you go to element 21 of a 20-element digital_pin_to_port_PGM array you get to element 1 of the digital_pin_to_bit_mask_PGM array: _BV(1). Bit 1 has the value 2 and the value 2 means Port B. I don’t know what is in element 21 of the 20-element digital_pin_to_bit_mask_PGM array in FLASH but any bits set to 1 will set the corresponding bits in DDRB to 0, making them INPUT. It must be a byte with bit 4 set to 1 since Pin 12 is Port B, bit 4.

Can we try that again in English…

…only kidding, I think I understand it. Basically one of my variables having bit 4 set that is crashing into a port-mapping variable.

It’s a good job we (you) found it now, rather than 3 months down the line when the variable achieves a “magic number”.

I must admit it had me totally flummoxed … 1400 on its way when I can : thanks again.

PS I will check ALL my sketches now in case I’ve made the same stupid mistake elsewhere. I definitely know that A7 is analog only, and don’t know how that got there, unless it was a search/replace …

daba:
PS I definitely know that A7 is analog only, and don't know how that got there, unless it was a search/replace ...

Then another thing to remember: You should only use pinMode() on a pin that you are using for digitalRead() or digitalWrite(). It appears that you were planning to use A7 to read from a floating line to get some entropy for random numbers. In that case there is no reason to use pinMode() on that pin.