Libc timezone functions

Hi,

I want to use the function "tzset()" declared under "time.h" to control the timezone.

This function is described in "GNU Tools ARM Embedded\4.9 2015q3\share\doc\gcc-arm-none-eabi\pdf\libc.pdf" in Chapter 8.11.

To be able to use it, I put the compilation optimization on "GNU ISO C99" instead of "ISO C99"

In the case of a project WITHOUT threadX tzset() works.

In the case of a project WITH threadX tzset() remains blocked.

I tried with "_tzset_r(_REENT)" under threadX but it does not work either.

Do you have a solution ?

Thank you

Phil

  • Hi Phil,

    I've tried to call this function inside ThreadX thread and it does not block further instructions. You may try disabling the use of newlib-nano in Project > Properties > C/C++ Build > Settings > Cross ARM C Linker > Miscellaneous > Use newlib-nano (--specs=nano.specs) - however I have the option enabled and it still works.

    Please note that the tzset() uses environment variables (TZ). Some useful notes can be found here: renesasrulz.com/.../calling-getenv-always-returns-null-pointer

    Regards,
    adboc
  • In reply to adboc:

    Thank you adboc,

    I removed the option (--specs = nano.specs) and actually the function tzset () works on a minimalist project with threadX.

    However when I removed this option in my "big" project several problems appear.

    I was first forced to increase the stack size of my threads to make it work.

    My project has 7 threads currently. 1 of these threads is in charge of the debug (printf on uart). In this particular thread I replaced the write function that is called by printf by my own custom function "_write".

    All my other threads that use printf with arguments work.

    However, when doing a printf WITH argument on the thread where I declare the environment variable (TZ), my program hangs!

    If I do a printf WITHOUT argument it works.

    What does the --specs = nano.specs option really do?

    Do you have an idea of what can happen?

    Regards,

    Phil

  • In reply to Phil:

    Hi Phil,

    This option enforces to use newlib-nano C library instead of newlib. It requires less memory than the full version.

    Where does your application hang? Can you suspend the execution and share a call stack?

    Regards,
    adboc
  • In reply to adboc:

    Hi adboc,
    How can I capture the stack under e2studio?
    Because I have a problem with "RTOS Resources" when I select the "stack" tab, e2studio hangs :(
    Regards,
    Phil
  • In reply to Phil:

    The thread stack should be shown in the Debug pane which is normally top left when in the debug perspective.

     

  • In reply to Ian:

    Thanks adboc & Ian,

    I found my problem, the size of a thread's stack was too small.

    But I don't know what is the minimum required stack size in order for the thread to work properly, because like I previously said : in "RTOS Resources" when I select the "stack" tab, e2studio hangs !

    Regards,
    Phil
  • In reply to Phil:

    This looks like it is to do with the thread stack sizes. Do you have any threads with very large stacks, say 64kB? At the moment the workaround is to reduce the stack size which of course may not be possible in every situation.

    Ian.
  • In reply to Phil:

    That is it. I have just tested with a 64kB stack and it causes a problem. It is unusual to have such large stacks though.

    Ian.
  • In reply to Ian:

    I have juste one thread with a 32Ko stack, the others have 8Ko
    Phil
  • In reply to Phil:

    Hi Phil,

    Hopefully this will be fixed in the future e2 Studio release, but for now you may find a stack buffer for the thread, fill the contents with some value e.g. 0xFE (recommended to do this at the begining of the application, e.g. in the tx_application_define_user), run the application for a while and see the last element that has a different value than 0xFE.

    For example:

    [0x01][0xA4][0x33][xFE][...][0x29][0xE9][0xFE][0xFE][...][0xFE]
                                         ^-------------------------- it's likely the last used element of the stack buffer during operation

    Regards,
    adboc

  • In reply to adboc:

    Ok thanks adboc,
    I will try this soon
    Phil