TLK110: About Software Strapping Mode

Hi Tao_2199,

The default values of these registers 0009,000A,000B are decided by the hardware straps and are pre-loaded before register access is available.
If any strap bit is re-programmed, the value programmed will take effect.

Please let me know if you need more details.

--
Regards,
Gokul.

Hi, Gokul-san,
Thanks for your answer.

In the customer's POWER ON / OFF test, they have found multiple TLK110s that do not operate normally about 5 times out of 10 times.
The phenomenon is that it does not LINK at 100base-T.
As a result of our investigation, we found the following.

1. Bootstrap uses internal pull-up / pull-down

2. Customer setting procedure
   ・ / SW_STRAP = L
   ・ Software sets only SWSCR1 = 0xFC01 at startup
   ・ It has been confirmed that there is no problem with the AC specifications of MDC and MDIO.

3. It works normally when H / W RESET is executed again.

4. We checked the following steps;

    CASE 1: Power on, / RESET release
          > Execute BMCR (0x0000) Reset [15]
          > SWSCR1 = 0x7C01 setting
          > SWSCR1 = 0xFC01 setting
         Result → NG

    CASE 2: Power on, / RESET release
         > Execute PHYRCR (0x001F) Software Reset [15]
         > SWSCR1 = 0x7C01 setting
         > SWSCR1 = 0xFC01 setting
        Result → NG

    CASE 3: Power on, / RESET release
        > SWSCR1 = 0x7C01 setting
        > SWSCR2 = 0x0004 setting
        > SWSCR3 = 0x0000 setting
        > SWSCR1 = 0xFC01 setting
       Result → OK

From the above results, I have some questions.

1. When POR did not work properly, I expected the same behavior as H / W reset with software reset, but it was different.
Is there a difference in Bootstrap loading between H / W reset and software reset? Also, is there a difference in the content that is initialized?

2. From your answer, the contents of the SWSCR register after POR reflect the contents of Bootstrap. Is it reflected by software reset?

3. When I read the SWSCR register after POR,
SWSCR2, 0x000a = 0x0104 is the default value, but a completely different value from 0x7f05 was set. As a result, the values ​​in some other registers were different from what was expected.
So, I rewrote everything from SWSCR1 to SWSCR3
It worked fine.

Is it an effective way to rewrite everything from SWSCR1 to SWSCR3 and operate it when the Bootstrap value is not reflected in SWSCR in POR?

4. Although the number is small, there are some individuals whose POR does not work properly. What are the possible factors that cause this?

Best regards,
Toshi

Hi Toshi-san,

Please find the replies below

1. When POR did not work properly, I expected the same behavior as H / W reset with software reset, but it was different.
Is there a difference in Bootstrap loading between H / W reset and software reset? Also, is there a difference in the content that is initialized?
[Gokul]: There is no difference in Bootstrap loading between H/W reset and software reset (0x001F[15]). Can you please provide logs and details of the differences you see?

2. From your answer, the contents of the SWSCR register after POR reflect the contents of Bootstrap. Is it reflected by software reset?
[Gokul]: Yes, they are reflected.

3. When I read the SWSCR register after POR,
SWSCR2, 0x000a = 0x0104 is the default value, but a completely different value from 0x7f05 was set. As a result, the values ​​in some other registers were different from what was expected.
So, I rewrote everything from SWSCR1 to SWSCR3
It worked fine.

Is it an effective way to rewrite everything from SWSCR1 to SWSCR3 and operate it when the Bootstrap value is not reflected in SWSCR in POR?
[Gokul]; It is strange that the register0x000A is read 0x7F05. If the read always 0x7F05? Or it happens only on some iterations?
Writing SWSCR1 to SWSCR3 is a good solution when a wrong value is reflected. 

4. Although the number is small, there are some individuals whose POR does not work properly. What are the possible factors that cause this?
[Gokul]: We will have to start the debug with monitoring power supply ramp and reset pin. What is the indication of failure you are observing? Is it observed always on few devices or across a few iterations?

--
Regards,
Gokul.

Hi, Gokul-san,
Thanks for your answer and support.

The actual phenomenon was different between H/W reset and Software RESET, so I read the data sheet again.

The data sheet explained as follows, and my assumption was wrong, and the confirmed phenomenon was found to be correct.

==== Excerpt from data sheet =====
Unless a new Power-up / HW reset was applied, the configured SW Strap Register values ​​will function as default values. Generation of Software Reset / Software Restart --bits 15 and 14 of register PHYRCR (0x001F) will not clear the configured SW Strap bit values.
=============================

By the way, according to the report from the customer, they are using a single 3.3V power supply. There is no observed waveform, but the rise time of the power supply is about 1.425ms.

When POR fails, the reserved bit of SWSCR2 is set to "1" where it should be "0".

In the sample where POR is prone to failure, it is a problem that occurred in the power ON / OFF test. Therefore, I tried cold start assuming the case where the electric charge inside the IC is not completely discharged when the power is turned off, but it has been confirmed that POR may not operate normally.
Replacing the problematic sample with a good one will solve the problem.

For reference, the contents of the register when OK and the contents of the register when NG are attached.

The execution steps are as follows.
Power on, / RESET release
> Execute BMCR (0x0000) Reset [15]
> SWSCR1 = 0x7C01 setting
> SWSCR1 = 0xFC01 setting

TLK110_OK_NG.xlsx

The number of problematic samples is small, but it is unclear why some samples are prone to POR failure.

Boootstrap uses an internal pull-up / down resistor. Is there any case where it is better to use an external resistor?

Thanks and regards,
Toshi

Hi Toshi-san,

I got the issue you are talking about. But, to debug this, we don't have ample support as TLK110 is phased out.

Do you mind letting me know the development stage you are current in with the TLK110 PHY?
If it's not too late, can you please switch to DP83822 which is pin-2-pin compatible with TLK110?

--
Regards,
Gokul.

Hi, Gokul-san,
Thanks for your answer and support.

Since it will be the information of our customers, I would like to reply with a private message from here.

Best regards,
Toshi

Hi Toshi-san,

Sure! We can take it up there.

--
Regards,
Gokul.

Hi, Gokul-san,
Thanks for your kind support.

There are new information and corrections.
It was reported that the value of SWSCR after POR or HW Reset was the default value in the IC that is easy to fail in the power on / off test. Initializing the value with POR or HW Reset does not seem to be a problem.

Therefore, it is the result of trying the following to see what the contents of the SWSCR registers will be for each step based on the customer's setting procedure.

1. Values ​​before writing SWSCR1, 2 and 3 after deassert of HW reset
      SWSCR1 = 0x7C01
      SWSCR2 = 0x0104
      SWSCR3 = 0x0000
2. Value after setting only SWSCR1 = 0x7C01
      SWSCR1 = 0x7C01
      SWSCR2 = 0x0104
      SWSCR3 = 0x0000
3. Value after setting SWSCR1 = 0xFC01 (Config_Done)
      SWSCR1 = 0xFC01
      SWSCR2 = 0x7F05
      SWSCR3 = 0x0000

When they rewrite only SWSCR1 and execute "SW Strap config Done", the contents of the register of SWSCR2 are strange for some reason.
It seems that this is the reason why the SWSCR-based Configuration did not work.

However, it works fine after executing "SW Strap config Done" after setting SWSCR1, 2 and 3.

An IC that has no problem in the power on / off test will operate normally without the SWSCR2 value becoming incorrect.

The question this time is why some ICs have incorrect SWSCR values ​​after running "SW Strap config Done" if all SWSCRs are not set.

Best regards,
Toshi

Hi Toshi-san,

Can you please let me know the delay between power supply ramp complete and the de-assertion of HW RESET? During power-up, what is the state of the RESET pin during the power-ramp?

On the bad boards, is the observation of SWSCR2  getting corrupted repetitive across HW RESET assertion/de-assertion and power-up cycles? Across all the power cycles, is the behavior happening only a few times or always?

--
Regards,
Gokul.

Hi Gokul-san,

Regarding Power ramp and RESET;
during power up, HW reset is asserted, deasserted when power is fully up, and then HW Reset is asserted again. It is deasserted after 600ms and SWSCR1 is set.

Regarding the matter that the contents of the register of SWSCR2 are destroyed;
They have not checked all the times, but it has been confirmed that the value of SWCSR2 is corrupted.
In the power ON / OFF test, the probability of normal operation is 50%, so it is estimated that SWSCR2 is also corrupted with a 50% probability.

The waveforms are sent to you by private mail.

Regards,
Toshi