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.

AM3359 PORz pin

Other Parts Discussed in Thread: TXB0102, TXS0102

So I am looking at the PORZ pin signal - this pin is driven directly by a TXB0102 with a 100K  Ohm pull down - there are no ther pins connected to this signal. The signal out of the level translator looks kind of funky and I am wondering if the processor is able to read the SYSBOOT with this waveform. I have attached a drawing I made of the signal (can't get a scope shot here). It appears that perhaps the processor is grabbing and controlling the PORZ signal once it hits about 0.8v. The signal into the TXB0102 has a nice clean rise.

I have seen this on other processors like the PIC's but I can't find anything in the documentation that says it does this.
Any explanation as to why the waveform would look this way and would it be causin me issues?
  • Hi Calum,
     
    The TXB0102 has very low output drive strength (4kOhm output buffer provides <100uA). Try removing the 100kOhm pulldown or else replace it with a TXS0102.
     
    Best Regards
    Biser
  • The PWRONRSTn terminal on AM335x is an input  so it should not be clamping the input signal if VDDSHV6 is within the recommended operating range of 3.14 to 3.47 volts.  This input is not fail-safe so the maximum input voltage is (VDDSHV6 + 0.3 volts).  Therefore, it could be the AM335x device if VDDSHV6 were only 0.5 volts while the input is clamped to 0.8 volts.  Check the supply voltage for VDDSHV6 while the input is clamped to 0.8 volts.

    I suspect this being caused by the auto-direction detecting level-shifter and you would still see this if the processor terminal was disconnected.

    Regards,
    Paul

  • Turns out that the 3.3v was not quite stable which was causing issues. However I am see ing a new issue.

    I have the sysboot pins configured for MMC0 boot but I never see teh MMC0_clk pin being driven. I do get CLKOUT1 at 24MHz but only for a couple minutes. It just stops and doesn't come back. Probably means the processor is not getting something it needs and finally shuts down.

    I have tried another board with the same result.

    Things I have checked.
    1. All the supplies are up and stable
    2. no unexpected PORZ or RTC_PORZ
    3. no NRESET_INOUT although I don't know what that does as default
    4. OSC0 inputs stable and at 24MHz
    5. When I was checking the supplies I looked at the CAP_VDD_RTC LDO output and it looks right (1.06v).

    I found something but I don't how critical it is.

    Page 100 of the datasheet shows the crystal connection. Mine is similar with one glaring difference. I also tied the VSS_OSC pin to my signal ground. The notes say not to do that. I can see the crystal operating normally but I don't know if this messes something up internally.
    Any help appreciated
    Calum
  • Hi Calum,
     
    Gan you give a little more background:
    • How are your sysboot pins configured?
    • Sysboot pullup/pulldown values?
    • Voltage to which sysboot pullups are tied?
    Thanks
    Biser
  • They are configured with pull ups and pull downs and with DIP switches to configure any way!!

    It turns out that we set the SYSBOOT pins to boot from Ethernet before looking at the MMC interface. For some reason the part sits and waits and does not timeout - does that seem right? We have changed the SYSBOOT pins to boot from MMC0 first and the board comes up.

    Calum

  • Hi Calum,
     
    Could be some errata issue. Have you checked the Errata document? Especially Advisory 1.0.18.
     
     
    Best Regards
    Biser
  • The VSS_OSC terminal was meant to be a Kelvin ground for the crystal circuit.  Connecting the VSS_OSC terminal to the PCB signal ground will not prevent the crystal circuit from oscillating, will couple unwanted noise into the AM335x clock circuits.

    The Ethernet boot code in the ROM will timeout and proceed to MMC, but it may take several minutes.  We realize this may not be acceptable for many applications.

    Regards,
    Paul