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.

AM62A3: eMMC and USB_VBUS questions

Part Number: AM62A3

Hey,

I'm an FAE for Amazon and they are using the AM62A3 in a new design. A couple questions below: 

  1. Their current design has the eMMC reset controlled by and AND gate with inputs from the AM62A RESETSTAZ and a GPIO. This is very similar to the AM62A-LP EVK design (see attached image) and we were curious why there would ever be a reason the software would want to reset the eMMC? Why do they do this on the EVM design?
  2. If we do have one of the AND gate inputs driven from an SoC GPIO, can you guarantee that the GPIO will not glitch or be configured by the bootloader and accidentally reset the eMMC?
  3. Are there currently any ways to print out the EMMC training results on UART? I think they would need to check from bootloader and from kernel as they might run at different speeds.
  4. The USB0_VBUS pin on the AM62 is used to detect an attached USB cable. I read section 9.2.3 of the datasheet, but I had a question on the detection threshold of this pin. I'm assuming it's simply an internal comparator that detects the VBUS voltage, but there is no info on what the comparator reference voltage is and the deviation of this detection threshold. Please elaborate on this as Amazon wants this info to understand external resistor tolerances, etc. 

  • 1. The GPIO reset option makes it possible for software to reset the attached eMMC device without resetting the entire processor if there is a case where the eMMC peripheral becomes unresponsive. You could eliminate the GPIO option and only use the warm reset output from AM62A3, where software forces a warm reset if the peripheral becomes unresponsive. However, this will reset the entire device rather than trying to recover the eMMC peripheral without resetting the entire device.

    2. All signal functions touched by each boot option in the ROM based boot code are defined in the TRM. You can prevent the ROM boot code from causing any problems by selecting a pin that is never touched by any of the selected boot options. I only provide software support, so I'm not able to answer this question with respect to any secondary bootloaders.

    Note: you should use an external pull to hold the GPIO signal high since most pins are turned off by default. You should also keep the output buffer disabled until the GPIO signal function has been selected via the pin mux logic and the GPIO associated with the pin is configured to drive a high logic state. Then enable the output buffer. The output buffer may produce a glitch if it is enabled while changing the pin mux logic to select a specific signal function.

    3. I will need to ask someone else to answer this question.

    4. The USB VBUS threshold has not been defined. We were told by the USB PHY design team to use the voltage divider clamp circuit as shown in the datasheet if you expect it to be compliant to the USB specification. They have not provided any additional information. However, there is a change pending for the circuit shown in the AM62Ax datasheet. The 3.5k ohm resistor value will be changing to 3.48k ohm so it is a standard 1% resistor value.

    Regards,
    Paul

  • Hi Cal,

    Are there currently any ways to print out the EMMC training results on UART? I think they would need to check from bootloader and from kernel as they might run at different speeds.

    The MMC training result is written to MMC PHY_CTRL4 register.

    In most cases, u-boot and kernel should train/configure eMMC to the same speed mode, unless a certain mode is disabled in either u-boot or kernel device tree.

  • Thanks Paul. 

    on question 4, I'm assuming the detection is just made with an internal comparator right? Are you able to provide what the internal detection threshold/reference is? Even if it's not listed on the datasheet, I would be curious to know. 

  • The circuit implementation and threshold value has not been disclosed in the USB PHY design documents. I ask the designers a similar question a few years ago. I was told we do not support USB implementations that are not compliant to the USB specification and there is no value in answering these questions because the PHY was design to be compliant to the USB specification when using with the external circuit shown in the datasheet.

    Why does Amazon feel they need to know this information? Are they trying to implement something that is compliant to the USB specification? If so, they should not need any additional information on how the VBUS detection works.

    Regards,
    Paul

  • Hey Paul,

    One more follow up on your question 2 response. Can we guarantee that the GPIO will not glitch? Keep in mind they are not using an I/O expander like in the EVM design. They are worried a glitch could accidently reset the eMMC. See the snapshot from their schematics below, you will notice the AND gate at the top of the screenshot and the GPIO from AM62A highlighted in green.

  • I already addressed the GPIO glitch concern in my previous reply. The glitch can be managed if they select a pin that is not touched by the ROM boot options which they plan to support and implement the proper GPIO initialization sequence in software.

    Regards,
    Paul

  • FYI, I was told the reset inputs on eMMC devices are disabled by default and it must be turned on by setting a bit in the eMMC non-volatile configuration space.

    Regards,
    Paul

  • Hey Paul. Can you elaborate on your comment regarding your note in question 2. you mention keeping output buffer disabled until GPIO signal function has been selected via the pin mux logic and configured to drive a high logic state. There is no buffer in their design (as you can see below) and the and gate they are using does not have an enable signal. But the EVM does not have a buffer with enable either, it also used an AND gate with a TCA6424ARGJR I/0 expander so just a bit confused on what you are getting at here. What would you recommend based on their below schematics? 

  • I was talking about the AM62A3 buffer enable, which has an over-ride called TX_DIS (bit 21) in the respective PADCONFIG register. You need to keep that bit set until MUXMODE (bits 3-0) is set to select the appropriate signal function. The output may glitch if you leave the output buffer enabled while changing the value of MUXMODE. The external pull will hold the logic state while the output buffer is disabled.

    Regards,
    Paul