yeah, while the board is running, its only possible to see that the red part of the led is somewhat flickering, but it more or less just looks green. It still helps me to see, at which line the code freezes. If its red, it froze at the serial.print (or at the setLED...).
I will try without the LED next. I already tried without the mpu (and just printing random floats instead).
oh, this edit about the tx buffer interesting! Thank you!
I added a routine just now in post #20 ...
Feel free to check that out!
The unblocking method is available for testing here
(Oops, we had Just some overlapping posts 
)
If you use the non-blocking routine you could add a counter like this
// global variable
int txFullCounter = 0;
...
// This skips sending if not enough space in TX buffer
if (Serial.availableForWrite() >= cnt) {
Serial.print(message);
} else {
txFullCounter++;
}
...
and in loop()
constexpr int maxTxErrors {20};
void loop() {
refreshLocalTimeEverySeconds(10); // Get the NTP time every 10 seconds only
measureEverymSec(10); // Measure every 10 ms
if (txFullCounter < maxTxErrors ) {
heartBeat(); // shows that loop() is still performing
} else {
setLED(255,0,0);
txFullCounter = maxTxErrors; // Just to prevent an overflow ;-)
}
This might be of interest as well:
import serial
import sys
comPort = '/dev/ttyACM0'
logFile = 'log.txt'
ser = serial.Serial(comPort,115200, timeout=0)
ser.flushInput()
f = open(logFile,'w')
print("Reading from: "+comPort)
print("Writing to : "+logFile)
print("------------------------")
while True:
try:
byteIn = ser.read()
if len(byteIn) != 0:
f.write(byteIn.decode())
sys.stdout.write(byteIn.decode())
sys.stdout.flush()
except:
print('------------------------')
print('Stopped')
f.close()
break
It's a Python script I wrote and posted already earlier this year that allows to log the Serial port an a PC (or Raspberry Pi). It may be of assistance for testing your code.
If youre still interested, here is what you were asking about, I think 
If you need more info, there are some files to load into CAD, here
This is a bit odd, because when I try this, the Serial.availableForWrite() is always smaller than cnt. cnt is about 75 and Serial.availableForWrite() is 64. Nonetheless I am able to print...
Completely leaving out all LED functionality and not importing the freertos led library still leads to a freeze btw
The standard buffer size is 64 bytes ... that's the reason...
As you are using an ESP32 there is a function
Serial.setTxBufferSize(256);
that allows to increase the Tx buffer. It's a function of the ESP Hardwareserial.
Well that's good, so that's not it !
If I do this (and Serial.setTxBufferSize(256);) it still freezes sadly.
I will try with a different board tomorrow (specifically UM Feather S2) to check if the board is at fault.
Thank you, for all the support so far!
Just some additional information from HardwareSerial.cpp:
size_t HardwareSerial::setTxBufferSize(size_t new_size) {
if (_uart) {
log_e("TX Buffer can't be resized when Serial is already running.\n");
return 0;
}
if (new_size <= SOC_UART_FIFO_LEN) {
log_e("TX Buffer must be higher than %d.\n", SOC_UART_FIFO_LEN); // ESP32, S2, S3 and C3 means higher than 128
return 0;
}
_txBufferSize = new_size;
return _txBufferSize;
}
So the correct way is to set tx buffer before Serial.begin():
Serial.setTxBufferSize(512-128); // See text below ;-)
Serial.begin(115200);
I tested it with one of my ESP32 Dev Kits.
It worked but takes a few prints until the change is reflected in Serial.availableForWrite().
Interestingly the available buffer for "Serial.setTxBufferSize(BUFSIZE); " was returned as follows
- if (BUFSIZE <= 128) the returned value was 128 (that's the minimum buffer as defined in soc_caps.h and set in HardwareSerial)
- if (BUFSIZE > 128) the returned value was BUFSIZE + 128
Therefore to get a txBufferSize of 512 you have to call for (512-128), for 1024 -> (1024-128) etc.
I tested several times over long hours with the UM Feather S2 and it doesnt freeze. So it probably has to do sth with our board or board support package.