This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TDA4VH-Q1: Customer Board Hardware Requirement of Supporting USB DFU Mode

Part Number: TDA4VH-Q1
Other Parts Discussed in Thread: TDA4VH, TDA4VM

Hi TI Experts,

Customer is working on TDA4VH SDK9.1.

As we could see from the datasheet below, The USB0_ID should be connected to ground for USB host operation or open-circuit for USB peripheral operation. May I know, does that mean in customer's board HW design they need to design two separate branches connecting to the USB0_ID? One is connecting to the ground, the other is leaving for open-circuit right?

The below is the customer's board HW design on USB0 currently. They found the problem that they could only work in the host mode but could not work in the device mode for DFU boot. They assumed our SoC internally support the open-circuit for the device mode. That's why in their board design they just connected 1 branch to ground to make it to the host mode.

I think the problem here is that our SoC internally do not support the open-circuit for that right? Hence, customer has to design 2 separate branches connecting to the USB0_ID, 1 for ground and 1 for open-circuit. Could you help to confirm this point please?

Thanks a lot!

Kevin

  • Hi Kevin,

    Yes, the USB0_ID should be connected to the ground for USB host operation or open-circuit for USB peripheral operation.

    May I know, does that mean in customer's board HW design they need to design two separate branches connecting to the USB0_ID? One is connecting to the ground, the other is leaving for open-circuit right?

    We suggest you read the USB spec to get clarity on this. You don't have to design two separate branches. The connector of the USB cable will this taken care.

    Please note that the TI EVM supports both host and device modes of operations and the USB0 has dual-role support. Suggest cross-checking the schematics with this for clarity.

    Thanks

  • Hi Praveen,

    Thanks for your reply!

    We have finally found the root cause about this problem, this is kind of surprising. Customer actually has made 2 generations of boards.

    For the first generation, according to our TDA4VH TRM, the backup boot mode config pin 7 for USB DFU is reserved. Customer made this pin as 0 (low) in their first generation boards. And they could work in the DFU boot. Also they have double checked that they could work in the DFU boot even in the host mode, as their customer board design does not have device mode currently.

    For the second generation boards, they made this pin to 1 (high). That is the problem that they could not work in the DFU boot. They have tried testing both host mode and device mode of USB0_ID in this situation, both are failed. Hence based on the experiment results, customer reworked their second generation boards and made this pin to 0 (low) again, then both host mode and device mode could work normally in DFU boot. And they have checked that in the DFU boot they could use the host PC to upgrade the board with no issues.

    In summary, there are below 2 points we may need your help to check.

    1: Why the backup boot mode config pin 7 can work in the DFU boot only when it is 0 (low)? For this question I also searched the TRM for another similar device called TDA4VM. In the TRM of TDA4VM, the description of this pin is below. It seems a little bit difference with that described in TDA4VH.

    2: Why in our experiment results, if we properly configured the bootmode pins, there seems no effect about the USB0_ID mode we applied. We have double checked that both modes seem could work for DFU boot. As customer only reserves the host mode in their HW design, they have concern that if we will fix this point in the future, then they may not work DFU boot in host mode in the new TDA4VH device. So shall we suggest customers still refer to our datasheet that having both host mode and device mode supported in their HW design?

    Kind Regards,

    Kevin

  • Hi Kevin,

    Also they have double checked that they could work in the DFU boot even in the host mode,

    What do you mean by this? What is the host mode referred here. Please note the the TDA4VH BootROM does not support USB host mode.

    Let us know.

    Thanks.

  • Hi Praveen,

    Thanks for your reply!

    I meant firstly we found that only when boot mode config pin 7 for USB DFU is set to 0 (low), the DFU boot could work.

    Secondly, as you could see below is customer's HW design, their USB0_ID is always in host mode which is connecting to the ground. For this situation, after we set the boot mode config pin 7 to low, it could work normally in DFU boot. Yes we know the DFU is ideally only can work when USB0_ID is in device mode. But seeing from the experiment results, it seems this USB0_ID pin does not affect the DFU boot process.

    What actually affecting the DFU boot is about the boot mode config pin 7 described above. It is reserved in the TRM, if we set it to high, then the DFU boot cannot work. If we set it to low then we could work.

    I will suggest customer still follow the datasheet and let them support both host mode and device mode for the USB0_ID in their HW design. Could you help check for the boot mode config 7 please? As it is reserved in the TDA4VH TRM, and it was stand for PORT in TDA4VM TRM, could you suggest why we need put it to 0 (low) so that we could work in DFU boot based on our experiment results?

    Thanks a lot!

    Kevin 

  • Hi Kevin,

    Please note that the if boot mode pin is either "not used" or "reserved"- it is always make sense to pull down this pin to ground. We are not sure why is the customer trying to set it as "high". It is a clear violation. 

    Please note that the TDA4VH BootROM working is best described in the TRM chapter 4  "Initialization". As noted, any boot mode pin not used must be kept low. Have the bit high will lead to the boot mode pin validation code in the BootROM as a invalid boot setting.

    Thanks.