No announcement yet.


  • Filter
  • Time
  • Show
Clear All
new posts

  • errno=15

    Because sometimes appears in yellow error:

  • #2

    Error Number 15, as per the Diablo16 Internal Functions Manual, states:

    15 EVE Stack Overflow
    Infinitely recursive program or
    insufficient Stack Size

    Do you have a function in your code, calling another function, which calls another function etc, and never returns?
    Ie you are running out of Stack due to never returning from your function.

    Please post your code if you are unsure.



    • #3
      yes, I have defined different mode menu screens in different functions, and only button on the menu exit goto to main function which is the principal function.


      • #4
        If you load a function, you need to return from it, otherwise you will consume memory and never free it. You cannot load a function, load another function, load another function, forever...
        You need to change your code.


        • #5
          How can you return to a caller function?
          Can you indicate an example?


          • #6
            You basically just 'drop out' of the main routine in the function, or use return if you want to return a value.

            The Picaso Designer, PICASO - DEMO folder and sum folders contain quite a few demos that call and return from functions.


            • #7
              Hi all.

              I have pretty much the same problem.
              In the main function of FLASH_BANK_0 I call

              i:= flash_Exec(FLASHBANK_1, buffer) ;

              I need to run program from flashbank_1. Sometimes when the program comes to this line, STACK OVERFLOW ERROR=15 accrues.
              What can I do to free some stack memory? The problem is, I'm working on a program that is larger than 32KB, so I need to use multiple FLASH BANKS. In the time when the program is in Flash bank 1, the timer in FLASH BANK 0 is still running. The timer is used for clock interrupt (1 second).

              What can i do?

              Best regards Ales Zupanc


              • #8
                You can define more stack using
                #STACK nnn
                in your program to ovrride the default of #STACK 200

                Of course, increasing the stack size will only defer the error 15 if your program is really infinitely recusing


                • #9
                  Hi everyone,

                  I am also having some problems with errno=15. The code is quite simple, 1 form, some bytes received from COM0 and some actions sent to COM2. I have checked the nested functions, there are up to 3 levels of nested functions, but no one with infinite loops that could lead to non-return problems.
                  In fact the code is working without problems in most of the screens, we have a long-time (24 hours) test for the screen application, and only in some of the 100 units we have found the errno=15.
                  We cannot really find a pattern for the reason leading to the error, it simply happens in some screens and in some of them very often while in others after running some minutes.

                  I have tried to increase the stack #STACK 4096, and it seems to solve the problem in the failing units. But why some units fail and other do not? hardware and software are identical in all the units.
                  Could be related with different delays executing internal functions in the screen, e.g. img_SetWord () or img_Show()?

                  Any other advice to debug this error?
                  Best regards


                  • #10
                    Hi everyone,

                    I think I found the source of errno=15 in my code. I am using bus_SetChangeInterrupt() to detects a change in 2 inputs lines. These two inputs lines come from magnets switches, which depending of their adjustment in the application were leading to not "pure transitions" between 0 (open) to 1 (close), ie. noise during the approaching (a series of transition before the final state). This in some units was leading to triggering the interrupt many times instead of only once. This random triggering of the interruption was the source of the stack overflow. I have modified the code for detecting the inputs without the interruption and now is running without problems in the failing units. At least for the moment
                    Best regards