• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 36 subscribers
  • Views 1103 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

DP83848i not performing a software reset.

David Hoffman21
Prodigy 40 points
Other Parts Discussed in Thread: DP83848I

Hi,

I am having a problem that I cannot explain why after I do a SW reset the PHY chip is in an unknown state. I have a lot of information to give you, depending on the questions you ask me. Let me start by giving you my setup.

I have an ATMEL AT91SAM7X256 rev C that is set to communicate with the DP83848i using MII. When I perfom a SW reset all the registers that I read (0,1,2,3,4,6,7,10,11,12,14,15,16,17,18,19,1a,1b,1d) are set to FF FF. In other words, when I write a 1 to bit 15 of the BMCR register, all the other registers have been set to FF FF and never, ever come out of that state. I can read any register listed above and I have verified that they are all FF FF. If I bypass the SW reset, the setup works fine and I can communicate over ethernet through the PHY chip.

ATMEL has just revved that chip to rev C. All our boards that have the rev B chip are working fine and when you do the SW reset and read the BMCR register, I always get the strapped value (0x00 31) and not all FF FF in the BMCR register.

Here is my question. What happens in the PHY chip when a SW reset is written to it? What could cause it to not complete that procedure? Given that the only thing that changed was the ATMEL chip, it would appear that it is the culprit. Could there be a signal from the ATMEL chip that is preventing the completion of reset? What kind of a signal and on what pin on the PHY chip could do this? Since information like this is not present in the Data Sheet, and I have norrowed my problem down to this cause and I cannot troubleshoot any further until I know how this SW reset behaves.

Ask me anything you need to know. Thanks in advance for all your help.

  • 0
    TI__Mastermind 31600 points

    David,

    We will review this and get back to you.

    Patrick

  • 0 in reply to Patrick OFarrell
    Prodigy 40 points

    Hi,

    Have you had any success with this problem? If not, any ideas on when you might have an answer? Thanks.

  • 0 in reply to David Hoffman21
    TI__Guru*** 125430 points
    A couple quick thoughts... Can you verify that the clocks to the PHY are still present in this scenario? I've seen scenarios on many other devices where the reset does not complete if a given clock is missing. What things changed in Rev C of the Atmel device? If you can summarize the things that changed that might help point us in the right direction as to why things aren't working.
  • 0 in reply to Brad Griffis
    Prodigy 40 points

    Hi,

    Yes the clock is still present, as it is constant and at the correct freq. of 25 MHz. Here is the changes of rev C of the Atmel chip.

    41.6.1 Embedded Flash Controller (EFC)

    41.6.1.1 EFC: Embedded Flash Access Time 2

    The embedded Flash maximum access time is 20 MHz (instead of 30 MHz at zero Wait State (FWS = 0). The maximum operating frequency with one Wait State (FWS = 1) is 48.1 MHz (instead of 55 MHz). Above 48.1 MHz and up to 55MHz, two Wait States (FWS = 2) are required.

    Problem Fix/Workaround
    Set the number of Wait States (FWS) according to the frequency requirements described in this errata.

    41.6.2 Ethernet MAC (EMAC)

    41.6.2.1 EMAC: Possible Event Loss when Reading EMAC_ISR

    If an event occurs within the same clock cycle in which the EMAC_ISR is read, the corresponding bit might be cleared even though it has not been read at 1. This might lead to the loss of this event.

    Problem Fix/Workaround
    Each time the software reads EMAC_ISR, it has to check the contents of the Transmit Status Register (EMAC_TSR), the Receive Status Register (EMAC_RSR) and the Network Status Register (EMAC_NSR), as the possible lost event is still notified in one of these registers.

    41.6.2.2 EMAC: Possible Event Loss when Reading the Statistics Register Block

    If an event occurs within the same clock cycle during which a statistics register is read, the corresponding counter might lose this event. This might lead to the loss of the incrementation of one for this counter.

    Problem Fix/Workaround
    None

    41.6.3 Peripheral Input/Output (PIO)

    41.6.3.1 PIO: Electrical Characteristics on NRST, PA0-PA30 and PB0-PB26

    When NRST or PA0 - PA30 or PB0 - PB26 are set as digital inputs with pull-up enabled, the voltage of the I/O stabilizes at VPull-up.This condition causes a leakage through VDDIO. This leakage is 45 μA per pad in worst case at 3.3 V.

    Problem Fix/Workaround
    It is recommended to use an external pull-up if needed.

    41.6.3.2 PIO: Drive Low NRST, PA0-PA30 and PB0-PB26

    When NRST or PA0 - PA30 or PB0 - PB26 are set as digital inputs with pull-up enabled, driving the I/O with an output impedance higher than 500 ohms may not drive the I/O to a logical zero.

    Problem Fix/Workaround
    Output impedance must be lower than 500 ohms.

    41.6.4 Pulse Width Modulation Controller (PWM)

    41.6.4.1 PWM: Update when PWM_CCNTx = 0 or 1

    If the Channel Counter Register value is 0 or 1, the Channel Period Register or Channel Duty Cycle Register is directly modified when writing the Channel Update Register.

    Problem Fix/Workaround
    Check the Channel Counter Register before writing the update register.

    41.6.4.2 PWM: Update when PWM_CPRDx = 0

    When Channel Period Register equals 0, the period update is not operational.

    Problem Fix/Workaround
    Do not write 0 in the period register.

    41.6.4.3 PWM: Counter Start Value

    In left aligned mode, the first start value of the counter is 0. For the other periods, the counter starts at 1.

    Problem Fix/Workaround
    None.

    41.6.5 Real Time Timer (RTT)

    41.6.5.1 RTT: Possible Event Loss when Reading RTT_SR

    If an event (RTTINC or ALMS) occurs within the same slow clock cycle during which the RTT_SR is read, the corresponding bit might be cleared. This can lead to the loss of this event.

    Problem Fix/Workaround:
    The software must handle the RTT event as an interrupt and should not poll RTT_SR.

    41.6.6 Serial Peripheral Interface (SPI)

    41.6.6.1 SPI: Bad Serial Clock Generation on 2nd Chip Select

    Bad Serial clock generation on the 2nd chip select when SCBR = 1, CPOL = 1 and NCPHA = 0. This occurs using SPI with the following conditions:

    • Master Mode

    • CPOL = 1 and NCPHA = 0

    • Multiple chip selects are used with one transfer with Baud rate (SCBR) equal to 1 (i.e., when serial clock frequency equals the system clock frequency) and the other transfers set with SCBR are not equal to 1

    • Transmitting with the slowest chip select and then with the fastest one, then an additional pulse is generated on output SPCK during the second transfer.

    Problem Fix/Workaround
    Do not use a multiple Chip Select configuration where at least one SCRx register is configured with SCBR = 1 and the others differ from 1 if NCPHA = 0 and CPOL = 1. If all chip selects are configured with Baudrate = 1, the issue does not appear.

    41.6.7 Universal Synchronous Asynchronous Receiver Transmitter (USART)

    41.6.7.1 USART: DCD is Active High instead of Low

    The DCD signal is active at High level in the USART Modem Mode. DCD should be active at Low level.

    Problem Fix/Workaround
    Add an inverter.

  • 0 in reply to David Hoffman21
    TI__Genius 10190 points
    Hi David,

    I’ve reviewed the SAM7X256 errata and do not see anything that jumps out:
    http://www.atmel.com/Images/Atmel_32-bit-ARM7TDMI-Flash-Microcontroller_SAM7X512-256-128_Datasheet.pdf

    The EMAC errata is the same between Rev B and C except RMII mode has been fixed on Rev C. The only “new” errata of interest was the “Embedded Flash Access Time 2” errata. Have you taken that into account?

    Questions:
    1. Are you polling the software reset bit to check if it self-cleared?
    2. Have you tried putting a delay between the software reset and further MII operation?

    Please advise.

    Thanks,
    Mark
  • 0 in reply to Mark Ackerson
    TI__Genius 10190 points
    Hi David,

    I'd also suggest checking your strap pins to make sure external IO is not loading the pins. Although it sounds like the device is booting properly with a hard reset. Have you tried performing a second software reset? I noticed errata related to software reset on SPI and TWI interfaces.

    Mark
  • 0 in reply to Mark Ackerson
    Prodigy 40 points

    I just wanted to post an update to this question. I have not had a chance to check, test, or verify the last 2 posts things that I could try since I am busy on other projects, but I do expect that I will revisit this in the future. For now, the reset of the PHY chip was disabled in code since it is strapped correctly with the behavior at start up. By doing this we are able to get past this problem and use the new Rev C ATMEL chips. It is stated in the documentation for the PHY chip that the software reset was not necessary if the PHY chip was strapped correctly. I will post new questions or comments at a later time so keep this thread open please.