Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
14 years ago

tse (Triple speed ethernet) and SGDMA (Scatter Gather DMA) do not seem fully connecte

So I've searched, and nothing seems to quite fit my case.

I am using SGDMA and TSE with InterNiche Portable TCp/IP v3.1 and Simple Socket Server demo and Altera 10.0 (or very close, maybe 10.1).

The interface device is apparently detected just fine (I am not including that info here, below info should make clear why I think its less than helpful), and I have hard coded the IP address to something easy (1.1.1.1, netmask 255.0.0.0).

If I hard-code the system's TCP/IP MAC address into a Linux box and send a ping to the board, the ping packets indeed show up inside the TSE buffer (as evidenced by the statistics counters), but nobody seems to be able to take them out. Indeed when the SSS tries to read from the TSE, it looks to me like SGDMA is not noticing that there is data in the buffers. Or maybe it cannot write or read from the source or destination.... In any case, the SSS never notices any packets, and to all intents and purposes the system is dead.

Some info dumped from my gdb activity is attached as the txt file. Salient portions, along with comments, below:

Note that I believe that 0x30000000 is the base address of the TSE MAC

register space, 0x30100000 is the base address of the SGDMA control,

and that 0x30300000 is the base address of the SGDMA descriptor as

shown below:

(gdb) p tse_ptr->currdescriptor_ptr

$33 = (alt_sgdma_descriptor *) 0x30300040

Now, just before pinging the board:

(gdb) x/100 0x30000000

0x30000000: ...same...

0x30000060: 0xffed0700 0x0000ffff 0x00000000 0x00000009 (*)

0x30000070: 0x00000000 0x00000000 0x00000000 0x000002e5

0x30000080: ...same...

0x30000090: 0x00000000 0x00000009 0x00000000 0x00000000

0x300000a0: ...same...

0x300000b0: 0x00000387 0x00000009 0x00000000 0x00000000

0x300000c0: 0x00000000 0x00000009 0x00000000 0x00000000

0x300000d0: ...same from there down...

just after pinging the board:

(gdb) x/100 0x30000000

0x30000000: ...same...

0x30000060: 0xffed0700 0x0000ffff 0x00000000 0x0000000d (*)

0x30000070: 0x00000000 0x00000000 0x00000000 0x00000435

0x30000080: ...same...

0x30000090: 0x00000004 0x00000009 0x00000000 0x00000000

0x300000a0: ...same...

0x300000b0: 0x0000051f 0x0000000d 0x00000000 0x00000000

0x300000c0: 0x00000000 0x0000000d 0x00000000 0x00000000

0x300000d0: ...same from there down....

Note the differences are highlighted above. In the past I have dug around in the documentation and convinced myself that at least one of those changes was due to the receipt of packets inside the TSE. (In fact, I believe that the 9 which changes to d (see '(*)' above) is 'aFramesReceivedOK', and indeed I sent 4 ping packets to the board)

In the attached file, I also dump what I think are the SGDMA descriptor and SGDMA control areas.

My current theory is that the SGDMA descriptor is somehow not set up right. But it all looks ok to me.

Is the above enough to confirm or deny? Any suggestions for more data gathering or pointers to what I've got wrong? (even pointers to the Fine Manuals would be appreciated at this point!)

Thanks!

Rusty

13 Replies

Show More
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Rats. I suppose that would have been too easy... Will keep working on that with the hardware guy.

    I do have another interesting issue. If I run the SSS under the debugger, the system initializes fine (find the PHY, negotiates GigE speed, etc).

    However, if I download and run without the debugger it never gets in to tse_mac_init, nor does it create any tasks or say 'prepped 1 interface, initializing...' as it does when I run in the debugger and do breakpoints and such (log of that available if anyone cares. I won't attach it unless someone wants to see it). (It does get in to prep_tse_mac, and it does figure out my MAC address (which I will admit to having hacked (hard-coded) a temporary mac address into))

    Quality time in debugger: I set my first breakpoint at tcpport.c line 60 (which says ' e = nptcp_init(); /* call the NetPort init in nptcp.c */'), load the elf for SSS (using 'nios2-download --tcpport 2323 sss.elf'), connect with debugger once download done, and then say 'continue'. It stops there (line 60), and then I say 'next' until I get to 'allports.c' line 402. At that point, I've succeeded in finding the PHY! Is there some sort of minimum time between loading the elf and letting it run that I need to obey???

    If anyone has seen any of this and/or has any ideas I'd appreciate hearing them!

    Thanks again!

    Rusty

    (By the way - for anyone else trying to debug the TSE - beware! If you try to single step line 213 of altera_avalon_sgdma.c which says:

    /* wait for the descriptor (chain) to complete */

    while ( (IORD_ALTERA_AVALON_SGDMA_STATUS(dev->base) &

    ALTERA_AVALON_SGDMA_STATUS_BUSY_MSK) ) ;

    Note that you WILL lock up your gdb session until that while terminates. Should the chain never complete your debugger is frozen and you have to kill the download process to get it back. Just consider it a feature, not a bug, since I've just documented it! ;-)
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    I've never used the debugger so I can't help a lot (I debug the good ol' way... LEDs and printf's :D ) but you have some really weird issues. You shouldn't have to wait before launching the application and it's hard to pinpoint the exact causes of those problems.

    Did you perform any low level verification of the board, such as a RAM test?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    My previous board did have a ram (DDR) issue, I will reload our code which has the ram test and re-run it on my new board....

    "I'm an expert, that's why I get the hard problems" :eek:

    LEDs? Wish I had some I could use... :) (Or, as some famous person almost said once: "LEDs? We don't need no steenking LEDs!")

    Anyway, thanks! I'll continue 'having fun' and update here once something useful/interesting/troubling/worth_mentioning happens.

    Rusty

    As a side note - I had trouble with printf debugging - I found that I only could do a certain number of them before the system died. If it weren't for that, I had seriously considered putting the 'Fred Fish Debug' macros (http://sourceforge.net/projects/dbug/) into the SSS so I could trace the program using printfs. VERY handy tools, those - highly recommended. (I worked at a place once that had them compiled into even their production code so that, should they need to debug the production code all they had to to was run it with debug enabled)