Losing TCP reception payload

[uTasker]

Hi All

I am using the ESP32S2-MINI in AT mode (125kBaud) via UART in order to upload new code to the main processor over a HTTP connection.
The new FW is about 800k in size but I find it randomly failing after typically about 128k of the upload - this various and so this is only typical but it is very often in this area.

What I find is that the processor receives 2920byte blocks of data.

When it fails I find that there is a byte missing in one of these blocks. It is random as to where in the block of data it is.

What is then seen is that one of two blocks later there is an additional byte and this is always 0x0d which is inserted.

The overall data length that is received is correct (but with one byte lost somewhere and one 0x0d inserted a little later).

At the moment am trying to exclude this behavior being due to UART data loss (although if that were the case the individual block lengths would likely be incorrect) but am wondering whether such behavior is known?

The HW being tested has in fact been in operation for several weeks an it was possible to do a number of uploads without problems and it may also be that this issue has started in one device.

Regards

Mark

[ESP_Sun]

Hi All

I am using the ESP32S2-MINI in AT mode (125kBaud) via UART in order to upload new code to the main processor over a HTTP connection.
The new FW is about 800k in size but I find it randomly failing after typically about 128k of the upload - this various and so this is only typical but it is very often in this area.

What I find is that the processor receives 2920byte blocks of data.

When it fails I find that there is a byte missing in one of these blocks. It is random as to where in the block of data it is.

What is then seen is that one of two blocks later there is an additional byte and this is always 0x0d which is inserted.

The overall data length that is received is correct (but with one byte lost somewhere and one 0x0d inserted a little later).

At the moment am trying to exclude this behavior being due to UART data loss (although if that were the case the individual block lengths would likely be incorrect) but am wondering whether such behavior is known?

The HW being tested has in fact been in operation for several weeks an it was possible to do a number of uploads without problems and it may also be that this issue has started in one device.

Regards

Mark

Hi,

It would be much appreciated if you could provide the following information.
1. AT command execution sequence that can reproduce the problem
2. Related AT version information (AT+GMR)
3. The data you tested after being replaced by 0x0d, and the original firmware you uploaded
4. You can lead out the TX and RX of the AT command serial port of the ESP device separately, and then connect it to the PC serial port tool, and output it in HEX format to see if the data obtained by TX and RX has been replaced with 0x0d. phenomenon, and save the log and upload it here.
Thanks again very much.

[uTasker]

Hello and thank you for your replay.

For the record, this is the AT+GMR command response:

AT version:2.1.0.0(0b76313 - ESP32S2 - Aug 20 2020 05:57:43)SDK version:v4.2-dev-2044-gdd3c032compile time(b5e1674):Aug 21 2020 05:00:52Bin version:2.1.0(MINI)OK

which should be the last release for the ESP32S2 MINI.

In the meantime I have had the opportunity to test the behavior on a number of different modules and have seen that only one of the modules has this particular behavior and all others behave normally.

Due to this it is very probably not a general issue but something local to that specific HW.

I will be doing more testing with the HW in question and will see if there is a soldering issue, or similar.
Assuming I don't identify something that can be reproduced on other boards I however conclude for the time being that what was being observed should not be a general issue.

In case I do find something that is general I will report again but for the meantime I think it can be left as something exceptional due to some form of HW problem.

Regards

Mark