Problems building uip1.0

  • Pontus Oldberg

    Pontus Oldberg - 2011-11-23

    Have anyone successfully managed to build and get uip1.0 or Contiki up and running using SDCC version 3.0.0 or 3.1.0 ? I have a code base that compiles and works very well with SDCC version 2.9.0. In a strive to get the tools up to date I installed 3.0.0 and tried to get it running but to no avail. It sort of works, but very unstable and ultimately hangs after running for a few minutes. Moving to version 3.1.0 is even worse, the unit starts and then hangs almost immediately. very frustrating.

    There are no warnings during the compilation.

    Is there anything particular that I should be looking for in the code base. It looks as if it is the webserver that causes the system to hang but I can't find anything wrong with.

  • Maarten Brock

    Maarten Brock - 2011-11-24

    Are you by any chance running out of stack space?

  • Pontus Oldberg

    Pontus Oldberg - 2011-11-25

    Ouch, I didn't think about that. I'll have a look this weekend. Are there any major changes in stack usage between 2.9 and 3.0 ? Because on 2.9 our application runs smoothly.

  • Maarten Brock

    Maarten Brock - 2011-11-25

    There are some optimizations that were disabled to fix certain bugs. This could lead to increased stack usage.

    What target are you using, which processor?

  • Pontus Oldberg

    Pontus Oldberg - 2011-11-25

    Aha, okay. We're using quite a lot of #pragma nogcse directives in our code to get around the fact that instance variables seem to go out of scope when using protothreads and psocks in uip. For instance the following:

    PT_THREAD(get_time_events(struct httpd_state *s, char *ptr) __reentrant)


      for(s->cgiv.i=0;s->cgiv.i < NMBR_TIME_EVENTS;++s->cgiv.i) {
        time_spec_t *ts;

        ts = &sys_cfg.time_events;
        if (ts->status & TIME_EVENT_ENTRY_USED) {
          PSOCK_GENERATOR_SEND (&s->sout, generate_time_events, s);


    will not work, instead I had to surround it with
    #pragma save
    #pragma nogcse
    #pragma restore
    after which it works as expected.

    Anyway, we use C8051F12x in our targets. No external memory.

  • Pontus Oldberg

    Pontus Oldberg - 2011-11-25

    Hmm, sorry 'bout the strike outs, don't know what happened.

  • Pontus Oldberg

    Pontus Oldberg - 2011-11-28

    It seem indeed that building our project with the 3.0 compiler gives us stack problems, causing the device to crash. Looks like we will be staying on 2.9 for this project and maybe add a stack monitor to ensure that we are staying inside bounds at all times.

    Maarten, thank you for the insight into this.


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks