• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 32 subscribers
  • Views 496 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TLK111 Intermittent packet transmission error

JOHN KEIGHTLEY
Prodigy 40 points
Other Parts Discussed in Thread: TLK111, DP83848C

Hi - we are interfacing to Ethernet 100baseT from an ARM STM32F207 in RMII mode using recommended Keil and STM layouts and software. We have built 30+ systems and encountered issues on 3 of these - On a system reset - ARM NVIC not a complete power cycle, the ethernet transmissions are 'garbled' as indicated by a duplicate system connected directly showing recvErrors on the RX_ER pin.

These errors occur continuously  on approximately every 2nd or 5th packet or 'never' after an NVIC reset. We believe this is some artifact of the initialisation sequence but have not been able to locate the root cause. We have changed the PHY to another TLK111 and/or the National DP83848C part and the 'problem' goes away. Putting the offending part back in causes the problem to return.

We cannot understand why a 'bad' system will work 'perfectly after one reset and then after the 'exact same' reset sequence, we have garbled packets.

Our concern is we do not understand what caused the problem in the first place and these systems are deployed in critical measurement applications worldwide with limited access to just change out a suspect system after initial deployment. 

  • 0
    TI__Mastermind 19780 points
    Hi John,

    Presence of RX_ERs usually indicates that there is an issue with the PHY's reference clock. Can you share the schematic? Is the STM32F207 providing the 50MHz reference to the TLK111 in the system you have?

    Regards,
  • 0 in reply to Rob Rodrigues
    Prodigy 40 points
    Hi Rob
    thanks for quick response. The PHY clock is generated from an external oscillator ( 25ppm) which also drives the ARM clock i/p. We are aware of the ST app note re not using the ARM to generate the PHY colock

    regards

    John
  • 0 in reply to JOHN KEIGHTLEY
    TI__Mastermind 19780 points
    Hi John,

    Great. Can you share a PN or datasheet for the oscillator? I'd like to see the jitter spec of the oscillator if possible.

    In addition can you show me the power up of the TLK111? Including the timing of the XI to the RESET of the ARM processor?

    A register dump as well of the offending PHY during "garbled" operation and normal operation would be helpful.

    Regards,
  • 0 in reply to Rob Rodrigues
    Prodigy 40 points
    Rob
    oscillator is FX0-HC536R-50

    We do not believe we are violating any power up timing - this problem is there or not on repeated software restarts of the ARM - NVIC - and no external power cycling is happening either of the ARM or PHY between good and bad runs. X1 is always present.

    Good and bad register dumps as below - these are identical except for 0x12 which changes as the PHY starts up

    GOOD
    >>>>>>>>>> PHY REGS >>>>>>>>>>

    GPIOG OSPEEDR 0x3FF00FFF OTYPER 0x00000000 OPUPDR 0x00000000

    Reg> 0x00 0x2100 Reg> 0x01 0x784D Reg> 0x02 0x2000 Reg> 0x03 0xA212
    Reg> 0x04 0x0181 Reg> 0x05 0x0000 Reg> 0x06 0x0004 Reg> 0x07 0x2001
    Reg> 0x08 0x0000 Reg> 0x09 0x1C00 Reg> 0x0A 0x0104 Reg> 0x0B 0x0000
    Reg> 0x0C 0x0000 Reg> 0x0D 0x0000 Reg> 0x0E 0x0000 Reg> 0x0F 0x0000
    Reg> 0x10 0x0605 Reg> 0x11 0x0108 Reg> 0x12 0x0000 Reg> 0x13 0x0000
    Reg> 0x14 0x0000 Reg> 0x15 0x0000 Reg> 0x16 0x0100 Reg> 0x17 0x0061
    Reg> 0x18 0x0440 Reg> 0x19 0x0421 Reg> 0x1A 0x0000 Reg> 0x1B 0x007D
    Reg> 0x1C 0x05EE Reg> 0x1D 0x0000 Reg> 0x1E 0x0102 Reg> 0x1F 0x0000
    M> 2048

    BAD
    >>>>>>>>>> PHY REGS >>>>>>>>>>

    GPIOG OSPEEDR 0x3FF00FFF OTYPER 0x00000000 OPUPDR 0x00000000

    Reg> 0x00 0x2100 Reg> 0x01 0x784D Reg> 0x02 0x2000 Reg> 0x03 0xA212
    Reg> 0x04 0x0181 Reg> 0x05 0x0000 Reg> 0x06 0x0004 Reg> 0x07 0x2001
    Reg> 0x08 0x0000 Reg> 0x09 0x1C00 Reg> 0x0A 0x0104 Reg> 0x0B 0x0000
    Reg> 0x0C 0x0000 Reg> 0x0D 0x0000 Reg> 0x0E 0x0000 Reg> 0x0F 0x0000
    Reg> 0x10 0x0605 Reg> 0x11 0x0108 Reg> 0x12 0x6000 Reg> 0x13 0x0000
    Reg> 0x14 0x0000 Reg> 0x15 0x0000 Reg> 0x16 0x0100 Reg> 0x17 0x0061
    Reg> 0x18 0x0440 Reg> 0x19 0x0421 Reg> 0x1A 0x0000 Reg> 0x1B 0x007D
    Reg> 0x1C 0x05EE Reg> 0x1D 0x0000 Reg> 0x1E 0x0102 Reg> 0x1F 0x0000
    M> 768

    John
  • 0 in reply to Rob Rodrigues
    Prodigy 40 points

    Rob

    any more insight on our issue here? We have done more testing including powering from two independent supplies ( ARM and PHY) and separate clocks - no change in symptoms.

    We have 5 failures out of 35 pcb assemblies - so absent any other information, we are going to attribute this to a production handling problem and/or defect of some kind, and going forward change the design to use the DP83848C part.

    Thanks for your assistance to date

    John