Forum Discussion

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

Problem in NicheStack TCP/IP

Hi,

I'm trying to implement NicheStack TCP/IP in my project I used the Simple socket server example when the program runs It gives me the log file in the below :

The problem is that the program goes into a loop and print this sentence :

*** tcp_sleep, OSMutexPost(2) = 4

dtrap - needs breakpoint

:confused: so what could be the problem?

please help me.

log file :

nios2-terminal: connected to hardware target using JTAG UART on cable

nios2-terminal: "USB-Blaster [USB-0]", device 1, instance 0

nios2-terminal: (Use the IDE stop button or Ctrl-C to terminate)

*** tcp_*** uCOS init, can't create global_wakeup_Mutex = 40

dtrap - needs breakpoint

=============== Software License Reminder ================

This software project uses an unlicensed version of the NicheStack TCP/IP

Network Stack - Nios II Edition. If you want to ship resulting object

code in your product, you must purchase a license for this software from

Altera. For information go to: "http://www.altera.com/nichestack"

=====================================================

Created "Inet main" task (Prio: 2)

Created "clock tick" task (Prio: 3)

InterNiche Portable TCP/IP, v3.1

Copyright 1996-2008 by InterNiche Technologies. All rights reserved.

prep_tse_mac 0

Your Ethernet MAC address is 00:07:ed:ff:cd:15

prepped 1 interface, initializing...

[tse_mac_init]

INFO : TSE MAC 0 found at address 0x08002000

INFO : PHY National DP83848C found at PHY address 0x01 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

OK, x=1, CMD_CONFIG=0x00000000

MAC post-initialization: CMD_CONFIG=0x04000203

[tse_sgdma_read_init] RX descriptor chain desc (1 depth) created

mctest init called

IP address of et1 : 192.168.1.234

DHCP timed out, going back to default IP address(es)

Simple Socket Server starting up

Created "Schools Embedded System Server" task (Prio: 4)

[sss_task] Simple Socket Server listening on port 30

*** tcp_sleep, OSMutexPend = 4

dtrap - needs breakpoint

*** tcp_sleep, OSMutexPost(2) = 4

dtrap - needs breakpoint

*** tcp_wakeup, OSMutexPend = 4

dtrap - needs breakpoint

*** tcp_wakeup, OSMutexPost = 4

dtrap - needs breakpoint

*** tcp_wakeup, OSMutexPend = 4

dtrap - needs breakpoint

*** tcp_sleep, OSMutexPost = 4

dtrap - needs breakpoint

*** tcp_sleep, OSMutexPend = 4

dtrap - needs breakpoint

*** tcp_sleep, OSMutexPost(2) = 4

dtrap - needs breakpoint

*** tcp_wakeup, OSMutexPend = 4

dtrap - needs breakpoint

*** tcp_wakeup, OSMutexPost = 4

dtrap - needs breakpoint

*** tcp_wakeup, OSMutexPend = 4

dtrap - needs breakpoint

*** tcp_sleep, OSMutexPost = 4

dtrap - needs breakpoint

*** tcp_sleep, OSMutexPend = 4

dtrap - needs breakpoint

nios2-terminal: exiting due to ^C on host

8 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Which quartus are you using?

    There is some problem with Niche Stack available with 8.1 .

    If you could copy it from some lower versions, 7.2, it might help
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Nichestack was updated at some point to require 3 task priorites (2, 3, and 4). In other words, move your "Schools Embedded System Server" task to a different priority. You're clobbering the required global mutex task.

    Cheers,

    - slacker
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Hi Slacker,

    could you please confirm this is a bug in NicheStack in which the tcp_sleep() and tcp_wake() functions do not work properly for tasks that call select()?

    if no, could you please guide me how to resolve this error? I am not sure with you solution posted.

    Thanks,

    Carid

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    I know for sure that there was a bug like that in the kit that was delivered with Quartus 7.2 and 8.0. It may have been fixed since that time though

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Hi Daxiwen,

    Thanks for your prompt reply.

    i am getting message like Hany Assasa's

    Simple Socket Server starting up

    [sss_task] Simple Socket Server listening on port 30

    *** tcp_sleep, OSMutexPend = 4

    dtrap - needs breakpoint

    *** tcp_sleep, OSMutexPost(2) = 4

    dtrap - needs breakpoint

    Created "simple socket server" task (Prio: 4)

    *** tcp_wakeup, OSMutexPend = 4

    dtrap - needs breakpoint

    *** tcp_wakeup, OSMutexPost = 4

    dtrap - needs breakpoint

    *** tcp_wakeup, OSMutexPend = 4

    dtrap - needs breakpoint

    *** tcp_sleep, OSMutexPost = 4

    dtrap - needs breakpoint

    *** tcp_sleep, OSMutexPend = 4

    dtrap - needs breakpoint

    I want to clarify this is a bug bout the tcp_sleep() and tcp_wake() functions do not work properly for tasks that call select() because I read Slacker's reply, it seems like moving the task to different priority solved the issue. Could you please advice?

    Thanks,

    Carid
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    In uCOS II you can't have 2 tasks that run at the same priority number. That's why Slaker gave the list of priorities used by the Niche stack (2,3 and 4). If one of your tasks is running at one of those priorities, you must move it to a different number.

    Except for that there can be multiple reasons for that dtrap message. I find that message quite annoying. The developers were too lazy to put real informative error messages and put this one instead. You need to run your application in debug mode and put a breakpoint on the dtrap() function. Then when the debugger freezes the application, you need to find out were dtrap() was called from. If you are lucky you'll find a comment above the dtrap() call that can give you some information about the problem.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Hi Daixiwen,

    Thanks for your clarification that this isn't a bug that i mentioned.

    so i will probably move the task to other priorities except 2,3,4. Am I right?

    Thanks,

    carid