I have a very strange problem. Im making a weather station project that uses GSM module, anemometer and temperature sensors. There are couple of different versions that i made in recent years but the latest one is giving me headache.
Before i was using atmega328p chip but i change it to newer 328pb mostly because of two hardware UART. In both versions im using MiniCore and almost the same software.
The problem is that arduino script crashes from time to time but the MCUSR is always 2 so i dont know where in code the crash happened. I have some checkup in code to use watchdog for reset in case of trouble and save "problematic location" in EEPROM which worked fine in last version but not here because it seems that script crashes before reaching watchdg.
To further debug i decided to plug serial module but it then did't crash even after serial days, but without serial module it crashes couple of times per day. I have no idea how to debug this further. What difference does it make if serial module is working or not ? Im 90% it has to do something with the GSM module. What could i do to find the source of issue ?
Do you have a while loop in the setup function that waits until the serial power is detected. If so without anything connected it will hold there forever.
You don't need this on the Uno anyway.
lastchancename schematic is aveliable here https://oshwlab.com/jaka87/new-vetercek If you are thinking power issues i dont think that is the case. It was also my first tought. But the serial module is also running from the same power and if it is connected script is working fine but without it sometimes crash.
pmagowan i was thinking the same. I made minimal working script without the sensors only GSM module and it still breaks. Just as i susspected. I will now try saving each state to EEPROM to see where it breaks.
Grumpy_Mike No, but i dont think it's the issue since i get the same issue if i comment it out. If this would be problematic it would newer work but it only sometimes dont.
Sorry but I find that hard to believe. If you do this it will stop your code running even if the rest of your setup is fine.
Please post all your code not just an irrelevant section. Because the section of code you did post has nothing to do with what I told you about in my post.
I meant that if I comment out #define DEBUG. Link to my code is in the first post. Unfortunately it is to big to paste it here.
After weeks of trying different stuff i think i am finally closer to solution. Like pmagowan said i did the minimal working script and find out the
digitalWrite(A2, HIGH);
is definetly causing the crash. Im not sure if it is because the pin is analog, I tried also with number 16 which should be arduino pin number for A2 but it still crashed.
For now i changed that part of the code to avoid using that pin but it still crashed once this afternoon. I am using digitalWrite twice in my script. Once to reset the module and once to power it on.
The crash is certainly not due to the digitalWrite(), but it could be a consequence of it, like incorrect wiring, inadequate power supplies or power supply decoupling.
Post a hand drawn wiring diagram, links to the modules and the complete code.
Then attach it as a file, or at least the minimal working script that shows the same fault.
How can anyone do anything but guess when they don't know what folly you have committed. A schematic, hand draw is fine Fritzing is not, and the code is the minimum we need.
No it is not. By using A2 you are actually specifying use the analogue pin as a digital one.
Do you mean reset the Arduino? If so that will not work, because the minimum reset time is not met, because the Arduino resets all pins to inputs, thus removing the reset signal.
If you’re confident of the power, so be it, but I’ve done a lot with SIM7600 modems, and the most difficult problems to find have been making sure the modem can get 2A ‘when it needs it’.
In reality, it runs most of the time at much lower currents (less than 200mA), but under the right (wrong) circumstances**, the 7600 needs all that power for 5-10 seconds, and if it isn’t there, the modem will not be part of your project again until it gets a full power cycle. (Soft power off-on isn’t enough to recover)
** cell negotiation, and sending multiple messages - even in good coverage areas.
I found out the issue is when i try to start serial connection with GSM module. I use reset function to restart the script. After restart function is run script restarts but after another 5-7s it crashes and restarts again. After that it runs fine. I found the point of crash is at moduleSetup function.
I will try my best to include the code i think is important... What keeps bugging me is that if i connect Serial logger works as expected and i dont understand why.
#define DEBUG
int resetReason = MCUSR;
HardwareSerial *fonaSS = &Serial;
#ifdef DEBUG
#include <NeoSWSerial.h>
NeoSWSerial DEBUGSERIAL( 5, 7 );
#endif
Adafruit_FONA_LTE fona = Adafruit_FONA_LTE();
void setup() {
MCUSR = 0; // clear reset flags
wdt_disable();
#ifdef DEBUG
DEBUGSERIAL.begin(9600);
delay(20);
DEBUGSERIAL.println(F("S"));
DEBUGSERIAL.println(resetReason);
#endif
pinMode(13, OUTPUT); // this part is used when you bypass bootloader to signal when board is starting...
digitalWrite(13, HIGH); // turn the LED on
delay(1000); // wait
digitalWrite(13, LOW); // turn the LED
delay(100);
pinMode(10, OUTPUT);
digitalWrite(10, LOW);
moduleSetup(); // Establishes first-time serial comm and prints IMEI
}
void reset(byte rr) {
EEPROM.write(15, rr);
delay(200);
#ifdef DEBUG
DEBUGSERIAL.print(F("err_r: "));
DEBUGSERIAL.println(rr);
#endif
if (rr==2 or rr==5){ powerOn(); }
delay(100);
wdt_enable(WDTO_60MS);
delay(100);
}
void moduleSetup() {
delay(3000);
fonaSS->begin(57600);
if (! fona.begin(*fonaSS)) {
#ifdef DEBUG
DEBUGSERIAL.println(F("NoF"));
#endif
while(1); // Don't proceed if it couldn't find the device
}
fona.println("AT+CIPMUX=0"); // single ip
fona.setNetLED(true,3,64,5000);
delay(100);
fona.setNetworkSettings(F(APN)); // APN
delay(100);
fona.setPreferredMode(GSMstate);
fona.enableSleepMode(true);
delay(100);
if (GSMstate==38) {
fona.set_eDRX(1, 5, "1001");
}
}
here is the part of the GSM library
boolean Adafruit_FONA::begin(Stream &port) {
mySerial = &port;
DEBUG_PRINTLN(F("try SIM700"));
// give 7 seconds to reboot
int16_t timeout = 15000;
while (timeout > 0) {
while (mySerial->available()) mySerial->read();
if (sendCheckReply(F("AT"), ok_reply))
break;
while (mySerial->available()) mySerial->read();
if (sendCheckReply(F("AT"), F("AT")))
break;
delay(500);
timeout-=500;
}
// turn off Echo!
sendCheckReply(F("ATE0"), ok_reply);
delay(100);
if (! sendCheckReply(F("ATE0"), ok_reply)) {
return false;
}
// turn on hangupitude
if (_rstpin != 99) sendCheckReply(F("AT+CVHU=0"), ok_reply);
delay(100);
flushInput();
DEBUG_PRINT(F("\t---> ")); DEBUG_PRINTLN("ATI");
mySerial->println("ATI");
readline(500, true);
DEBUG_PRINT (F("\t<--- ")); DEBUG_PRINTLN(replybuffer);
if (prog_char_strstr(replybuffer, (prog_char *)F("SIM7000A")) != 0) {
_type = SIM7000A;
} else if (prog_char_strstr(replybuffer, (prog_char *)F("SIM7000C")) != 0) {
_type = SIM7000C;
} else if (prog_char_strstr(replybuffer, (prog_char *)F("SIM7000E")) != 0) {
_type = SIM7000E;
} else if (prog_char_strstr(replybuffer, (prog_char *)F("SIM7000G")) != 0) {
_type = SIM7000G;
}
return true;
}
Kicking on the GSM module spikes the power supply current. Your source is sagging enough to cause a reset until next init. Power source & schematic please. Serial has computer PS (very stiff) behind it so no crash then. GSM peak is 2A which is right at the hairy edge of the max possible on USB -- nothing left to run CPU. plus USB's are designed as CHARGERS where 1/2 a volt of sag doesn't matter, but logic is a bit fussier. Lots of USB ports don't support 2A but are limited to 1/2A. If this is the case your project will never work.
This is a HW issue, not SW.
Here is the schematic. I dont think its power issue. Project is battery powered but even if i connect it to charger for additional power this still happens.
However this issue newer happens if i connect Serial modue that is powered by the board itself. If power would be a issue this would happen even more often with Serial module plugged which draws additional power.
madmark2150 this is only limit for solar charging, pcb is powered by batery that can produce 3A or more and power IC is capable of delivering it. On the almost the same board that uses software serial instead of hardware there is 0 issue.
Another thing i find out is that is that this crash dont happen random but there is a pattern which makes to me further proves its not a hardware issue.
By pressing reset button or running watchdog timer and then leave to run its course this crash happens every second time.
for example:
reset press...led blinks (settings in setup)... few seconds later another reset (led blinks), MCUSR 2
wait for the script to start sending data...
reset press.. led blinks only once (normal start), MCUSR 2
wait for the script to start sending data...
reset press...led blinks (settings in setup)... few seconds later another reset (led blinks), MCUSR 2
......
or by using watchdog to reset
watchdog reset, 2 led blinks, MCUSR 2
wait for the script to start sending data...
watchdog reset 1 led blink, MCUSR 8
wait for the script to start sending data...
watchdog reset, 2 led blink, MCUSR 2
...
What i cant seem to figure out is what is different between one reset and another ?
In datasheet it is written that power pin should be pulled down so changing it to high does not make sense at first glance but i guess with using a diode the default voltage is so low that it is considered LOW and then after the LED blinks and the other procedures which takes more than 1s that is required for GSM modem to be pulled down and then changing it to high just works.
Now it works every time as expected. Thank you all for your help.
I think i finally know what is going on. Apparently arduino has auto reset function when new serial device is connected. So when i turn the module on it then resets and it does not crash like i thought. I guess that is different than software serial that i have been using in previous versions.
That explains why it doesn't "crash" when serial monitor is connected and I restart the script and also why keeping the power pin high (module does not restart) also does not produce the same behavior.
Apparently solution is to put 10uF cap on RST pin and GND or to put 100 ohm resistor on RST and VCC.