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 ?
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?
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:
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.
[0x01][0xA4][0x33][xFE][...][0x29][0xE9][0xFE][0xFE][...][0xFE] ^-------------------------- it's likely the last used element of the stack buffer during operation