AM2434: USB Full-Speed Mode Enumeration Failure on Specific Hardware Units

Hi YenTing,

Yen Ting Liu said:

Board B + Full-Speed firmware → PC fails to enumerate the USB device

Is this happening randomly or does it fails every time? Also please confirm the J23 header is not shunted (host mode).

Please refer section 3.4.11 USB 2.0 Interface of the User-guide for details. 

Yen Ting Liu said:

Under the settings in the referenced E2E post, does Full-Speed mode use a different USB PHY compared to High-Speed mode?

No, the USB PHY is same for both Full Speed and High Speed operations.

Yen Ting Liu said:

Is it possible that some USB hardware paths (e.g., internal PHY or IO buffers) were damaged, perhaps due to prior overcurrent/ESD tests, resulting in the inability to drive D+ low or respond correctly in Full-Speed mode?

Please allow some time to check this internally, are there any hardware anomalies which can cause USB to not work in Full speed mode. 

Regards,

Tushar

Hi Tushar,

I help YenTing response.

Tushar Thakur said:

Is this happening randomly or does it fails every time? Also please confirm the J23 header is not shunted (host mode).

Yes, it fails every time.
It seems no J23 header in our hardware. Is there any AM24 register to check host/device mode of USB.

Tushar Thakur said:

Please allow some time to check this internally, are there any hardware anomalies which can cause USB to not work in Full speed mode. 

Thank you! Please let us know if any known limitations exist.

Hi Frederick,

Frederick LIN said:

Yes, it fails every time.

Thanks for the confirmation.

Is this Board A and Board B both are same? Or board A is TI EVM but Board B is custom hardware?

Frederick LIN said:

 Is there any AM24 register to check host/device mode of USB.

You can check USB3P0SS_W1 registers Modestrap value to check in which mode controller is operating.

Please refer below image.

Regards,

Tushar

Hi Tushar,

Tushar Thakur said:

Is this Board A and Board B both are same? Or board A is TI EVM but Board B is custom hardware?

Both Board A and Board B are custom hardware. Boards A and B are identical in design, but they are different instances.

Tushar Thakur said:

You can check USB3P0SS_W1 registers Modestrap value to check in which mode controller is operating.

Please refer below image.

I checked the USB3P0SS_W1[18:17] is b'10, it is Device mode (both Board A and Board B).

We have confirmed that on Board B, which fails to enumerate in Full_Speed mode, the device is able to receive the GET_DESCRIPTOR request from the PC. Specifically, we observed that the request reaches the DCD_EVENT_SETUP_RECEIVED case inside the tud_task_ext() function in usbd.c.

Furthermore, the code proceeds to call process_get_descriptor(), and eventually invokes tud_control_xfer() to send back the descriptor. However, no response is observed on the physical D+/D− lines by logic analyzer — meaning the device appears to handle the request in software, but nothing is actually transmitted electrically.

Is there any recommended method or register-level check to help confirm whether this issue is due to a hardware fault, particularly in the USB PHY or output driver?

Hi Tushar,

Regarding the issue on Board B where the device fails to respond electrically on D+/D− despite software reaching tud_control_xfer(), do you have any recommendations or known debugging methods to further confirm whether this is a hardware-related issue, particularly within the USB PHY or output driver?

Additionally, in your response on another thread (AM2434 Tiny USB Module Application Affect the Others IRQ Trig Timing), you mentioned that TI generally does not recommend configuring USB in Full-Speed mode.

Could you please elaborate on the reason for this recommendation? We are evaluating potential design adjustments and understanding the limitations or concerns with FS mode would be very helpful.

Regards,

YenTing

Hi Yeng,

I am still checking on the above, are there any HW anomalies. For me if it works for HS, it should work for FS as well because the controller logic is same for both HS and FS mode.

Yen Ting Liu said:

Additionally, in your response on another thread (AM2434 Tiny USB Module Application Affect the Others IRQ Trig Timing), you mentioned that TI generally does not recommend configuring USB in Full-Speed mode.

You can use the USB in FS mode, but the above thread is using FS mode as workaround for interrupt miss/delay issue. TI was not claiming that FS mode would fix the interrupt miss/delay issue.

The reason why TI was not recommending this as a workaround for the issue because of no enough data point to identify why interrupt miss issue didn't occur when controller is fixed to FS mode. 

Regards,

Tushar 

Hi Yeng,

Could you please help me with the hardware connections.

Direct or CMC (Common mode choke) or series resistor used on the data interface signals?

regards,

Sreenivasa

Hi Yeng,

Can you please additionally confirm the package used.

Regards,

Sreenivasa 

Hi Yeng,

Are you seeing the issue on a specific bard or multiple boards.

Sreenivasa

Hi Sreenivasa

Kallikuppa Sreenivasa said:

Direct or CMC (Common mode choke) or series resistor used on the data interface signals?

We are using a common mode choke on the D+ and D− lines.

Kallikuppa Sreenivasa said:

Can you please additionally confirm the package used.

If you're referring to the SDK version we're using, it's AM24 8.6.0.45.

Kallikuppa Sreenivasa said:

Are you seeing the issue on a specific bard or multiple boards.

We are seeing this issue on two specific boards.
On one of them, we identified that the USB VSS line is damaged. Interestingly, Full-Speed mode works when we directly connect the USB VSS bypass the broken bead.
The root cause on the other board is still unknown at this point.

Regards,

YenTing

Hi Yeng,

Thank you.

Yen Ting Liu said:

We are seeing this issue on two specific boards.

Refer below inputs i received from the expert:

Full speed and High speed use the same PHY, but different transmitters within the PHY.  The 3.3V transmitters  are used for Low speed and the low voltage current driver  is used for High speed transfers.  So it may be possible to damage the 3.3V transmitters without damaging the low voltage current driver.

Was the non-working board initially working or never worked?

Do you have the required protection on the USB interface.

Are you able to share the USB interface schematics for a quick check?

Regards,

Sreenivasa

Hi Sreenivasa

Kallikuppa Sreenivasa said:

Was the non-working board initially working or never worked?

The non-working board has never worked in FS mode. However, it's not a brand-new board—it might have been damaged during our experiment before we try FS mode on it.

Kallikuppa Sreenivasa said:

Are you able to share the USB interface schematics for a quick check?

I will send you the layout design via private message.

Regards,

YenTing

Hello YenTing

Thank you.

Let me review the inputs.

Any thoughts on the number of boards built/tested.

Regards,

Sreenivasa

Hello YenTing

Please refer below inputs i received previously from the device expert:

Kallikuppa Sreenivasa said:

Refer below inputs i received from the expert:

Full speed and High speed use the same PHY, but different transmitters within the PHY.  The 3.3V transmitters  are used for Low speed and the low voltage current driver  is used for High speed transfers.  So it may be possible to damage the 3.3V transmitters without damaging the low voltage current driver.

Regards,

Sreenivasa

Hi Sreenivasa

Kallikuppa Sreenivasa said:

Any thoughts on the number of boards built/tested.

We’ve tested FS mode on approximately 20 boards so far, and only two of them failed to operate in FS mode.

To ensure FS functionality, we’ve also included an FS mode check in our QC process for brand-new boards, and so far, there has been no negative feedback.

Kallikuppa Sreenivasa said:

Please refer below inputs i received previously from the device expert:

We plan to replace the AM24 chip on the non-working board to further investigate the issue.

Best regards,

YenTing

Hello YenTing

Thank you for the note and update on the testing.

Regards,

Sreenivasa

Hello YenTing

Quick comments 

The USB interface seems to be configured for device functionality? Please check the ID status?

I do not see any cap near to the connector - can you please conform

The VBUS divider does not seem to follow the data sheet recommendations, please verify

The ferrite at the input of the VBUS divider can be a DNI

Importantly SOC USB interface is not fail-safe - the USB interface is expected to be disabled before the SOC is powered off and connected after the SOC is powered and all supplies relevant to USB interface ramp and are stable.

Regards,

Sreenivasa

Hi Sreenivasa

Kallikuppa Sreenivasa said:

The USB interface seems to be configured for device functionality? Please check the ID status?

I do not see any cap near to the connector - can you please conform

The VBUS divider does not seem to follow the data sheet recommendations, please verify

The ferrite at the input of the VBUS divider can be a DNI

Importantly SOC USB interface is not fail-safe - the USB interface is expected to be disabled before the SOC is powered off and connected after the SOC is powered and all supplies relevant to USB interface ramp and are stable.

The USB is configured as device mode. We appreciate your suggestions regarding the USB peripheral hardware design. We will review and improve the related circuitry accordingly.

After testing, we found that replacing the AM24 chip on the non-working boards resolved the issue — the boards are now working properly in FS mode.

Regards,

YenTing