- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi!
I have my board with CYCIII + 2 PHY KSZ9021GQ. During debugging web_server under NIOS i have error out "TSEMAC SW reset bit never cleared!". And correspondingly does not start web-server (no web-server in browser). Who encountered a similar error? Log start: InterNiche Portable TCP/IP, v3.1 Copyright 1996-2008 by InterNiche Technologies. All rights reserved. prep_tse_mac 0 Your Ethernet MAC address is 11:22:33:44:55:66 Static IP Address is 192.168.3.250 prepped 1 interface, initializing... [tse_mac_init] INFO : TSE MAC 0 found at address 0x04002000 INFO : PHY Micrel KSZ9021GQ found at PHY address 0x1f of MAC Group[0] INFO : PHY[0.0] - Automatically mapped to tse_mac_device[0] INFO : PHY[0.0] - Restart Auto-Negotiation, checking PHY link... INFO : PHY[0.0] - Auto-Negotiation PASSED INFO : PHY[0.0] - Checking link... INFO : PHY[0.0] - Link established INFO : PHY[0.0] - Speed = 100, Duplex = Full TSEMAC SW reset bit never cleared! OK, x=10002, CMD_CONFIG=0x00002000 MAC post-initialization: CMD_CONFIG=0x04000200 [tse_sgdma_read_init] RX descriptor chain desc (1 depth) created mctest init called IP address of et1 : 192.168.3.250 Created "Inet main" task (Prio: 2) Created "clock tick" task (Prio: 3) Created "web server" task (Prio: 4) Web Server starting up :( Signals on MII - input to TSE: https://www.alteraforum.com/forum/attachment.php?attachmentid=5148 Signals on TSE - output from FIFO of TSE: RX https://www.alteraforum.com/forum/attachment.php?attachmentid=5149 TX https://www.alteraforum.com/forum/attachment.php?attachmentid=5150Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Could You post the driver source for KSZ9021GQ chip?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- Could You post the driver source for KSZ9021GQ chip? --- Quote End --- driver source for KSZ9021GQ chip: https://www.alteraforum.com/forum/attachment.php?attachmentid=5151
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Are You sure You're reading the correct registers?
Also I see that signaltap shows reset signal down, which indicates, that the system has hardware reset, rather than software reset.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- Are You sure You're reading the correct registers? Also I see that signaltap shows reset signal down, which indicates, that the system has hardware reset, rather than software reset. --- Quote End --- In Triple Speed Ethernet User Guide.pdf: https://www.alteraforum.com/forum/attachment.php?attachmentid=5152 What is logical level for this signal in TSE 0 or 1? Reset in qsys https://www.alteraforum.com/forum/attachment.php?attachmentid=5154 This signal from pin with pull-up resistor.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Oh, I thought this reset is not for the TSE core, but for the chip itself. The chip has reset_n pin. I don't have 9021GQ, but on 9021GN it's pin 56, which has to be pulled high. Check it's state with scope.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- Oh, I thought this reset is not for the TSE core, but for the chip itself. The chip has reset_n pin. I don't have 9021GQ, but on 9021GN it's pin 56, which has to be pulled high. Check it's state with scope. --- Quote End --- I am check reset signal on chip. The reset_n signal for 9021GQ is pin 110 - it always in 1 and it pulled high in my schematic. Led Link100 and RX on 9021GQ is active - chip not in reset. schematic in attachment https://www.alteraforum.com/forum/attachment.php?attachmentid=5155
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Something wrong with the attachments, but anyway, the problem is somewhere in the software then. You should read out PHY registers and check for real values, because the driver could possibly read wrong values if the setup is not correct.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It seems that your tx_clk isn't toggling. What interface do you have between the MAC and the PHY? Is it regular MII?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- It seems that your tx_clk isn't toggling. What interface do you have between the MAC and the PHY? Is it regular MII? --- Quote End --- Probably that's because he use the same clk as sampling clock in signaltap.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- It seems that your tx_clk isn't toggling. What interface do you have between the MAC and the PHY? Is it regular MII? --- Quote End --- I have MII interface between PHY and MAC.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
SW_RESET in Command_Config Register.
Software reset. Set this bit to 1 to trigger a software reset. The MAC function clears this bit when it completes the software reset sequence. When reset is triggered, the MAC function completes the current transmission or reception, and subsequently disables the transmit and receive logic, flushes the receive FIFO buffer, and resets the statistics counters. Why SW reset bit never cleared?- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If that description is correct, I don't think it is valid to wait for it to be cleared.
The clock on the MII interface is generated by the PHY, and its speed depends on the negotiated link speed. In the absence of a cable (etc) this clock is very likely to be stopped - so the current rx/tx can never complete. You either need some more robust 'hardware reset', or be willing to leave the MAC unit 'in reset' until the PHY has finished negotiating the link speed (etc) with its peer.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Last log in Debug:
InterNiche Portable TCP/IP, v3.1 Copyright 1996-2008 by InterNiche Technologies. All rights reserved. prep_tse_mac 0 Your Ethernet MAC address is 11:22:33:44:55:66 Static IP Address is 192.168.3.250 prepped 1 interface, initializing... [tse_mac_init] INFO : TSE MAC 0 found at address 0x04002000 INFO : PHY Micrel KSZ9021GQ found at PHY address 0x1f of MAC Group[0] INFO : PHY[0.0] - Automatically mapped to tse_mac_device[0] INFO : PHY[0.0] - Restart Auto-Negotiation, checking PHY link... INFO : PHY[0.0] - Auto-Negotiation PASSED INFO : PHY[0.0] - Checking link... INFO : PHY[0.0] - Link established INFO : PHY[0.0] - Speed = 100, Duplex = Full TSEMAC SW reset bit never cleared! TSEMAC aFramesTransmittedOK=0x00000000 TSEMAC aFramesReceivedOK=0x00000000 TSEMAC aFrameCheckSequenceErrors=0x00000000 TSEMAC aAlignmentErrors=0x00000000 TSEMAC aOctetsTransmittedOK=0x40021e0 TSEMAC aOctetsReceivedOK=0x040021f0 TSEMAC aTxPAUSEMACCtrlFrames=0x04002200 TSEMAC aRxPAUSEMACCtrlFrames=0x04002210 TSEMAC ifInErrors=0x04002220 TSEMAC ifOutErrors=0x04002230 TSEMAC CMD_CONFIG=0x00002000 OK, x=10002, CMD_CONFIG=0x00002000 MAC post-initialization: CMD_CONFIG=0x04000200 [tse_sgdma_read_init] RX descriptor chain desc (1 depth) created mctest init called IP address of et1 : 192.168.3.250 Created "Inet main" task (Prio: 2) Created "clock tick" task (Prio: 3) Created "web server" task (Prio: 4) Web Server starting up This is Statistics Counters (Byte Offset 0x060 – 0x0E0) of TSE- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hm, nothing special here... Check differences in MDIO registers between 88E1111 and KSZ9021. E.g. check if software reset bit is in the same place?
P.S. I suppose ethernet is not working right?- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- Hm, nothing special here... Check differences in MDIO registers between 88E1111 and KSZ9021. E.g. check if software reset bit is in the same place? P.S. I suppose ethernet is not working right? --- Quote End --- Hm, i think software reset it is register of TSE IP? Embedded Peripherals IP User Guide Table 25–7. Control Register SW_RESET Software can reset the core by writing to this bit twice. Upon the second write, the core is reset. The logic which sequences the software reset process then resets itself automatically. Executing a software reset when a DMA transfer is active may result in permanent bus lockup until the next system reset. Hence, Altera recommends that you use the software reset as your last resort.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi all,
i am sorry, i didnot read all discussion, but i have question. Is possible to use Micrel KZS9021RL/RN or KSZ9021GQ with Tripple speed ethernet driver or Igor MAC driver in uClinux ? I found that i am not possible to buy anywhere Marvell 88e1111. Now i use with success PHY DP83848 with Igor MAC IP with uClinux, but my colleague want to try gigabit phy. Thank you for your answer. Jan Naceradsky- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Having a quick look at the product brief, this PHY should work with the TSE mac. But you will probably need to modify the driver to add a profile with the correct MDIO registers and functions in order to support it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Okay, but i havent any experiences with repairing driver for uclinux, maybe it will take me one man-year:)) and my boss will be ungry:).
Which PHYs use after marvel 88e1111 ?- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm not familiar with the uClinux drivers. But if you have a look at the driver code, you should find somewhere a list of the supported PHYs.
For the uCOS / Interniche drivers, you will find them in the alt_tse_phy_add_profile_default() function in altera/*/ip/altera/triple_speed_ethernet/lib/sopc_builder/altera_triple_speed_ethernet/HAL/src/altera_avalon_tse.c . On my installed version (11.1) here is the list I have: [list][*]Marvell 88E1111[*]Marvell 88E1145[*]National DP83865[*]National DP83848C[/list] The National DP83865 is a gigabit PHY, but you should check first whether support for the PHY has been ported to the uCLinux driver. Or maybe uCLinux has a unified PHY driver architecture, independent from the MAC driver? If a uClinux specialist is around...- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page