Forum Discussion

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

System hangs when c-code is smaller

Hello!

A friend and I have programmed a NIOS-System using the Altera WebServer example as SOPC-Design. In the uCos we create three Tasks and do some decoding and output of encrypted audio-data, that worked all quite well. The program was running as we wanted it. Then we cleaned our code and added comments after we finished development. Now while we remove some old functions that were still in the design from our development process, but they are not used by us anymore, the hole system hangs while running on the development board.

By variation of the amount of c-code, that we remove from the project, the moment when the system hangs can be altered, so we believe it has to do with the stack and heap. The problem is, that this behavior is really bad to debug, because we have no experience with it.

The problem must occur in the NicheStack while receiving an packet we think, but when we debug, the debugger steps over the moment where the error must occur and we land somewhere in the memory afterwards. What would you do in such a moment and how would you try to solve such a problem.

We already dumped our elf, but got no clues from that. We tried to raise debuglevel and look into the code with debug, as mentioned above we just see that an error occur, but not what happens there. We activated stack check and OSTaskCheck tells us, that the stack is big enough.

Where or how to pinpoint this behavior?

Thanks for any advice,

Peter.

3 Replies

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

    We programmed and tested initial with Quartus 10.1sp1. Now we have set up an virtual machine with Quartus v11.0 installed and in the NIOS EDS get the following information at the same point the system in 10.1sp1 just hang. What can you see from this messages: 

    
error: conn_receive
conn_mana
dtrap - needs breakpoint
dtrap - needs breakpoint
panic: m_free: type
dtrap - needs breakpoint
ip_exit: calling func 0x56808
netclose: closing iface Altera TSE MAC ethernet
ip_exit: calling func 0x5e324

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

    If you really think the problem is due to stack or heap you can try to increase their size or conversely reduce their usage. This latter can be done if your application uses several levels of nested calls or big local variables/arrays: reduce the nested calls and especially declare big variables inside functions as 'static'

    Please note that problems similar to yours can often arise if you have timing problems.

    Is your fpga design fully constrained and does it meet timing?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Hi Cris72 and thanks for the reply,

    the design is from Altera the standard WebServer example. It is constrained but got hold timing violations in the Ethernet RX clock path. I always thought that could harm the project, but as I learned only the setup violations really are the critical violations, so we just ignored that warnings.

    We found the problem after my friend spend another night looking into the code. It was an buffer that was not initialised after the cleanup of the code and so the program run berserk in the sdram we think. With that buffer created it is now running again. It is really bad, that there isn't a tool that checks all the pointers and buffers for you before compilation, that could have saved us a lot of time.

    The problem is solved right now. :D

    Thanks.