Hi,
I have deleted my previous post as it incorrectly described my issue as I had modified the example which I was using a bit.
I will explain my issue again, hope someone can tell me what is wrong
I am creating a simple TCP to Serial and Serial to TCP device.
I have a custom board with Atmega2560 and w5500.
The arduino will act as a TCP server and a laptop will connect as a TCP client. There is serial data coming on the serial port after the client connects once and initiate handshake. Before that there is no data coming from the serial port.
Now, if the handshake does not happen and the serial data has not started yet, then if I close the TCP session, or remove the Ethernet cable, nothing unusual happens and I can connect to the server after cable reconnection.
But if the serial data had been initiated earlier and the TCP connection is close or the cable removed, after reconnection I am unable to ping my PCB from the laptop.
I suspect the code crashes in this case due to some reason as the serial port is getting flooded with data.
But I do not understand what I have to do to cater it in the code, if it is the problem.
Any help is appreciated. The problem may be something else, this is just my guess.
So the trick is to figure out what is going on inside the microcontroller on your custom board.
Two ways I can think of:
Use a debugger appropriate for the Atmega2560
Use a second UART on the 2560 to output diagnostic data to (i.e. Serial.print) and capture that on a console of your choice.
Having taken an extremely brief glance at your code, the first thing my eye falls on is a routine in which you write serial data to a 2000-byte array with no apparent protection of writing outside the boundaries of this array. I'm referring to the checkSerial function in misc.cpp starting from line 173.
That's literally the first thing I see; if there's that one, I bet there are other, similar problems going on. Diagnostics as indicated above should help you locate the problem.
given that he only writes serialCharCount bytes and it's initialized as
the serialCharCount can't be larger than the Serial buffer (64 bytes) unless that was modified in the project. So 2000 is plenty - and possibly too much for the stack.
Thanks to both of you for the response.
I had earlier kept the buffer smaller (but still bigger than 64)
I am making the following changes and will see if I get any more issues
void checkSerial() {
char c[63] = {0}; // initialize with all zeros as zero signifies string ending
uint32_t serialCharCount = Serial.available(); // returns number of characters available in serial buffer
if (serialCharCount >63){
serialCharCount = 63;
}
if (serialCharCount > 0) { // read only if there is data in serial buffer
if (Ethernet.linkStatus() == LinkON) { // Check Ethernet connection status
if (g_localDataclient.connected() || g_remoteDataclient.connected()) {
for (uint32_t count = 0; count < serialCharCount; count++) {
c[count] = Serial.read();
}
if (g_localDataclient.connected()) {
g_localDataclient.write(c, serialCharCount);
}
if (g_remoteDataclient.connected()) {
g_remoteDataclient.write(c, serialCharCount);
}
} else {
// Read and discard the serial data if no clients are connected
while (Serial.available()) {
Serial.read();
}
}
} else {
// If Ethernet connection is not available, read and discard the serial data
while (Serial.available()) {
Serial.read();
}
}
}
}
OK, I hope it helps. I do think you'll be stumbling in the dark as long as you don't set up some kind of diagnostics of what's happening inside the microcontroller at runtime. In my experience, it's very frustrating and time-consuming to troubleshoot without feedback.
At the very least, break out a GPIO to a LED or something so you can light that if your code reaches a certain point.
I can relate; I've had to do kludges on PCB's quite often to diagnose problems. It's usually possible to solder some bits of wire to a GPIO and thus break out one or two pins for diagnostics. Give it a try; it's probably quicker than trying to blindly troubleshoot the issue.