FTDI Driver doesn't report state change on any modem signals from FTDI chip (IEC-461)

[Rotario]

Answers checklist.

• I have read the component documentation ESP-IDF Components and the issue is not addressed there.
• I am using target and esp-idf version as defined in component's idf_component.yml
• I have searched the issue tracker for a similar issue and not found any related issue.

Which component are you using? If you choose Other, provide details in More Information.

device/esp_tinyusb

ESP-IDF version.

v5.0

Development Kit.

Custom board

Used Component version.

2.0.0

More Information.

Behavior depends on compiler implementation and may vary between GCC versions or optimization levels.

Current Code

managed_components/espressif__usb_host_ftdi_vcp/usb_host_ftdi_vcp.cpp - `FT23x::ftdi_rx()

new_state.bRxCarrier =   data[0] & 0x80; // Extract bit 7                                     
new_state.bTxCarrier =   data[0] & 0x20; // Extract bit 5                                     
new_state.bBreak =       data[1] & 0x10; // Extract bit 4                                     
new_state.bRingSignal =  data[0] & 0x40; // Extract bit 6                                     
new_state.bFraming =     data[1] & 0x08; // Extract bit 3                                     
new_state.bParity =      data[1] & 0x04; // Extract bit 2                                     
new_state.bOverRun =     data[1] & 0x02; // Extract bit 1                                     

Where cdc_acm_uart_state_t is:

typedef union {                               
    struct {                                  
        uint16_t bRxCarrier : 1;              
        uint16_t bTxCarrier : 1;              
        uint16_t bBreak : 1;                  
        uint16_t bRingSignal : 1;             
        uint16_t bFraming : 1;                
        uint16_t bParity : 1;                 
        uint16_t bOverRun : 1;                
        // ... more fields                    
    };                                        
    uint16_t val;                             
} cdc_acm_uart_state_t;                       

Expected Behavior

Bitwise AND correctly extracts the bit, and the 1-bit field is set to:

• 1 if the extracted bit is set
• 0 if the extracted bit is clear

Example: If data[0] = 0x80 (bit 7 set):

• data[0] & 0x80 → 0x80 (non-zero)
• Assign to bRxCarrier → bRxCarrier = 1

Actual Behavior

The bit value is lost during assignment:

• data[0] & 0x80 → 0x80
• Compiler truncates to fit 1-bit field → takes LSB of 0x80 → 0
• Assign to bRxCarrier → bRxCarrier = 0

Result: The extracted bit value is inverted or lost depending on bit position.

I've tested this with a null modem cable and another FTDI chip connected to my PC. Running a short python script asserting DTR does not trigger the event_changed callback because of this bug

If I update the assignments to this
managed_components/espressif__usb_host_ftdi_vcp/usb_host_ftdi_vcp.cpp - `FT23x::ftdi_rx()

 new_state.bRxCarrier =   !!(data[0] & 0x80);                                                                                                                                                 
 new_state.bTxCarrier =   !!(data[0] & 0x20);                                                                                                                                                 
 new_state.bBreak =       !!(data[1] & 0x10);                                                                                                                                                 
 new_state.bRingSignal =  !!(data[0] & 0x40);  
 new_state.bFraming =     !!(data[1] & 0x08);  
 new_state.bParity =      !!(data[1] & 0x04);  
 new_state.bOverRun =     !!(data[1] & 0x02);  

Then the state change handling works

Here's the python script I run it with
./rs232_slow_receiver.py --dsrdtr --rtscts --no-xonxoff --port /dev/ttyUSB0
rs232_slow_receiver.py

[github-actions]

Hi @Rotario! Please be aware that the following suggestions are generated by a bot and haven't been fact-checked by Espressif Systems. We hope that this message will help you until an Espressif Engineer looks at your issue.

---

You’re right: given the current code and the cdc_acm_uart_state_t definition, the assignments are incorrect and can indeed cause the modem status bits to be lost or mis‑reported.

From the component docs, usb_host_ftdi_vcp is a thin wrapper on top of the CDC‑ACM host driver and is expected to correctly map FTDI modem status bits into cdc_acm_uart_state_t so that higher‑level code can react to DTR/RTS and other signals. [FTDI VCP driver; CDC‑ACM host]

Given:

typedef union {
    struct {
        uint16_t bRxCarrier : 1;
        uint16_t bTxCarrier : 1;
        uint16_t bBreak : 1;
        uint16_t bRingSignal : 1;
        uint16_t bFraming : 1;
        uint16_t bParity : 1;
        uint16_t bOverRun : 1;
        // ...
    };
    uint16_t val;
} cdc_acm_uart_state_t;

and the current code:

new_state.bRxCarrier =   data[0] & 0x80;
new_state.bTxCarrier =   data[0] & 0x20;
new_state.bBreak =       data[1] & 0x10;
new_state.bRingSignal =  data[0] & 0x40;
new_state.bFraming =     data[1] & 0x08;
new_state.bParity =      data[1] & 0x04;
new_state.bOverRun =     data[1] & 0x02;

assigning a non‑normalized mask (e.g. 0x80) into a 1‑bit field is undefined/implementation‑dependent; some compilers will effectively take only the LSB of the masked value, which is 0 for all these masks. That matches your observation that modem‑state changes are never reported.

Your proposed fix:

new_state.bRxCarrier =   !!(data[0] & 0x80);
new_state.bTxCarrier =   !!(data[0] & 0x20);
new_state.bBreak =       !!(data[1] & 0x10);
new_state.bRingSignal =  !!(data[0] & 0x40);
new_state.bFraming =     !!(data[1] & 0x08);
new_state.bParity =      !!(data[1] & 0x04);
new_state.bOverRun =     !!(data[1] & 0x02);

first normalizes each expression to 0 or 1, which is the correct and portable way to assign into 1‑bit fields. This is consistent with how other Espressif USB/CDC code normalizes status bits before storing them in small fields. [CDC‑ACM host]

So for the GitHub reply, you can say:

1. This is a real bug in usb_host_ftdi_vcp’s handling of modem status bits.
2. The root cause is assigning raw masked values (e.g. 0x80) directly into 1‑bit bitfields, which is not portable and can yield 0 on some compilers/optimization levels.
3. The correct fix is to normalize to a boolean (0/1) before assignment, e.g. using !!(mask) as you proposed.
4. With this change, DTR/RTS changes from the FTDI chip are correctly propagated and the event_changed callback is triggered, as you observed with your Python test script.

Since this specific bug and patch are not yet mentioned in the published component docs or changelog, it would be helpful if you open (or keep open) the GitHub issue and include your patch snippet; the maintainers can then integrate it into a new usb_host_ftdi_vcp release.

[igi540]

Hi @Rotario ,
You’re correct about the root cause: these fields are 1-bit bitfields, and assigning data[x] & MASK directly can get truncated to the LSB when stored in a 1-bit field. We will fix it.
Thank you for your detailed report.

[udoudou]

Changing the field type in cdc_acm_uart_state_t to bool fixed the issue in my tests.

typedef union {
    struct {
        bool bRxCarrier : 1;  // State of receiver carrier detection mechanism of device. This signal corresponds to V.24 signal 109 and RS-232 signal DCD.
        bool bTxCarrier : 1;  // State of transmission carrier. This signal corresponds to V.24 signal 106 and RS-232 signal DSR.
        bool bBreak : 1;      // State of break detection mechanism of the device.
        bool bRingSignal : 1; // State of ring signal detection of the device.
        bool bFraming : 1;    // A framing error has occurred.
        bool bParity : 1;     // A parity error has occurred.
        bool bOverRun : 1;    // Received data has been discarded due to overrun in the device.
        bool reserved : 9;
    };
    uint16_t val;
} cdc_acm_uart_state_t;

[igi540]

Fixed in commit 56080cb (merged)