event.size in UART_BREAK is sometimes strange/wrong (IDFGH-11129)

[Bloeckchengrafik]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

v5.1

Operating System used.

Windows

How did you build your project?

VS Code IDE

If you are using Windows, please specify command line type.

CMD

Development Kit.

ftSwarm [https://elektrofuzzis.github.io/en/index.html]

Power Supply used.

External 3.3V

What is the expected behavior?

Working with uart, I get UART_BREAK events with the correct event.size provided.

What is the actual behavior?

Sometimes event.size has values above MAX_BUF_SIZE, sometimes up to MAX_INT.

Steps to reproduce.

1. uart_set_mode( [UARTNUM] , UART_MODE_RS485_COLLISION_DETECT)
2. xQueueReceive(RS485_queue, (void * )&event, 10000 )
3. do:

switch (event.type) {
    case UART_BREAK:
        if (event.size > 512) {
            printf("%ul", event.size);
        }
}

4. run some communication

Debug Logs.

No response

More Information.

No response

[songruo]

Hi @Bloeckchengrafik, event.size field is meaningless with UART_BREAK event type. The value you got is just an uninitialized number, which I am now aware of. I will fix this by initializing it to 0 in the driver to reduce confusion.

[AxelLin]

@songruo Why it takes such long time for this trivial fix?

[igrr]

@AxelLin This bug has been evaluated as having low impact. The fix has been added to another (larger) change of UART driver, and that change is still being reviewed. If this bug causes trouble in your project, please let us know and we can split it and merge it separately. I think it is an easy thing to work around in the application, though.

[AxelLin]

@igrr
I agree this is a minor issue.
However, IMHO, you should split this fix from other rework.
One fix per issue, no matter it's high or low priority. (Not just for this issue)

When people notice the status changed to Reviewing state, people expect it to be fix soon.
But now the "Status" field becomes meaningless, because the fix is stuck due to unrelated rework.
Non-espressif people has no idea about what's going on for a trivial fix taking very long time to review.
e.g.
Is the fix get forgotten?
Or is the fix actually discovers other side-effects and is actually more complex so it takes longer time?

[AxelLin]

Hi @Bloeckchengrafik, event.size field is meaningless with UART_BREAK event type. The value you got is just an uninitialized number, which I am now aware of. I will fix this by initializing it to 0 in the driver to reduce confusion.

@songruo
So when will you fix this?