Ethernet PHY reset

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Ethernet PHY reset

3,998 Views
pozz
Contributor III

Dear Forum,

I'm new with Kinetis microcontroller, so most probably my questions will be very stupid. Sorry for that :smileyhappy:

 

I'm going to use a K60 microcontroller coupled with an Ethernet PHY connected by RMII mode. The PHY will be DP83848C from National.

 

After reading schematics of TWR-SER and TWR-K60N512, I noticed the RESET input signal of PHY is connected to PTE27 pin of microcontroller. This pin is also connected to SD_WP (I think write protect of SD card bus).

 

Is this signal actually used in the example codes? Is PTE27 configured and used as a GPIO? How the PHY reset behaviour is shared with SD write protect?

I tried to search in example codes, but I couldn't find the point where the PTE27 is used as a custom output reset.

 

If I understood well, PTE27 pin can be used as a GPIO or as RTS signal of UART4. Does this mean that I can't have a UART4 with hw flow control?

0 Kudos
5 Replies

1,823 Views
mjbcswitzerland
Specialist V

Hi

 

On the kits that I have the PHY reset input is connected to RESET_B (the main processor reset). It may be that this has been changed on newer boards (TWRSER2) but I couldn't find a circuit diagram of it to verify. In any case, it is often useful to be able to control the RESET of the PHY in order to be able to ensure that any power-up delays are respected (depends on PHY type) and that the strap input (shared with other signals) can be forced into the correct state by processor GPIO when the PHY leaves reset.

 

This is not required on the TWRSER (original version) with Micrel PHY, where the RESTE_B is adequate.

 

If there is a conflict with the SD card WP input it may be a minor design error on the evaluation board and one would have to avoid inserting a write protected card when working with Ethernet. The boards are meant to allow first simple tests and should not always be seen as a perfect reference. It may also be that the reference SW doesn't include (full) support for the new serial board and so doesn't control the line, which would of course need to be programmed as output and driven high after reset.

 

In the case of the RTS line, the UART4's RTS signal can be set to either PTE27 or PTC12, so RTS doesn't need to be lost.

 

The Tower kit only attaches UART3 to the serial output, although there are 6 possible UARTs multiplexed to various port possibilities. Basically the tower kit shows only one or two of a large number of possible configurations and so is not necessarily suitable for basing a new design on, which will be much more flexible.

 

Regards

 

Mark

 

 

0 Kudos

1,824 Views
pozz
Contributor III

Dear Mark,

 

I'm using TWR-SER too and the PHY reset signal is connected to pin A63 of primary elevator, named RSTOUT_b.

 

In TWR-K60N512 schematics (rev. D) (sheet 8) I see A63 pin of primary elevator connected to A11 of the same connector and PTE27 of MCU (pin J4). The signal RESET_B (pin L12) is connected to A62 pin of primary elevator. It seems to me they are two very different signals: one is an output for the MCU, the other is an input.

 

 

 

 

 

0 Kudos

1,824 Views
mjbcswitzerland
Specialist V

Hi

 

Now I see - it is the processor board that has changed. I have the Rev. C of the board which is a bit different.

 

This has also been discussed here:

https://community.freescale.com/message/85692#85692

 

because the WP also stops the TFT from working if there is a card in the slot - possibly also Ethernet (?)

 

As noted before, the designs are not always perfect but I think that the change was to allow more control of the reset line (possibly for other new modules) but has caused some difficulties/collisions in some circumstances.

 

My boards have a few tracks cut and signals placed at other positions to make things possible that weren't with the basic design - but no big deal - the boards are for playing with...

 

Regards

 

Mark

 

 

0 Kudos

1,824 Views
pozz
Contributor III

Hi Mark,

 

so there was a change on the CPU module from rev. C to rev. D, but I couldn't understand the reason.

 

In rev. C, all the reset input pins (PHY, CPU...) are connected to the main reset section (manual reset switch/automatic

reset from OSBDM microcontroller). So all the sections are in reset state at the same time with the MCU.

 

I'm not an expert with these microcontrollers and I initially don't want to change the code available from Freescale too much.I haven't investigated too much in the example codes so I don't know if the new RESET signal from MCU in rev. D is managed or not.

 

Do you suggest to use the connection in rev. C or rev. D?

 

0 Kudos

1,824 Views
mjbcswitzerland
Specialist V

Hi

 

As noted in the previous post I think that the change was to help control the reset of peripherals (other boards) since the main RESET can not be controlled by the CPU itself.

 

I recommend using a mixture of RESET and port outputs to control the reset of external peripherals. In many cases RESET is appropriate since there is no special timing required and it is not necessary to be able to selectively reset certain peripheral.

 

In cases of external peripherals which may need a longer reset signal that that of the Kinetis (some PHY need 100ms, for example) or when it should be possible to selectively reset the peripheral during operation (and it doesn't support command to do this) it will be useful to control it via a port. In this case the port should be dedicated to the job (assuming there are free ports available) and would be use an external pull-down resistor to hold the reset state until the Kinetis has configured its output.

 

For Ethernet PHY I would generally recommend using a GPIO as reset since there are cases where this extra control can be very useful (mainly to ensure that its strap inputs are in a defined state when its reset signal is negated).

 

Regards

 

Mark

 

0 Kudos