This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Hi Andre,
It looks like a tricky issue. Can you please check that you have no calls to routines that lead to IDE specific implementation (for ex., printf leading to display on terminal IO)?
Best regards,
Naveen
Hi Naveen, thanks for the feedback.
Originally suspected that it might have something to do with the IDE/debugger intialization, but have already done the following:
a) Replaced all (sn)printf functionality with my own xprintf based on printf-stdargs with floating points support from Georges Menie (http://www.menie.org/georges/embedded/) and
b) replaced putchar with my own xputchar to go directly to the UART port MAP_xxxxxxx
b) #define printf xprintf
#define sprintf xsprintf
#define snprintf xsnprintf
c) Checked that NOTHING more comes out on the CIO console screen, all redirected to UART terminal session
d) Set compiler options to assume no printf support included (no difference made)
Any further suggestions?
What concerns me is that even after everything above the following symbols are still reflected in the linker map:
rtsv7M4_t_le_eabi _printfi and sprintf()
__TI_printfi and __TI_printfi and sprintf
Morning Naveem,
Further update on the above.
I have found the source of the sprintf and hence the _printfi function(s). In FreeRTOSConfig.h I was using both
#define configUSE_TRACE_FACILITY 1
#define configUSE_STATS_FORMATTING_FUNCTIONS 1
By changing the second one to 0 it removed the reliance on sprintf and made the code a bit smaller.
As it stands now the map file ONLY shows references to xprint, xprintf, xsprintf and xsnprintf, all my function that talk directly to the UART.
The bad news is that it has made no difference to the behaviour of the program, it still does not move any further.The task list comes up and all tasks run (or try to in case of Exosite) except for SLSPAWN which continues to show a single timer tick having been used, nothing more.
What do you suggest next.
Andre
Hi Andre,
Do you see the issue if you try a simpler usecase? Probably a single task, doing sl_start --> wlan_connect -->does something -->wlan_disconnect-->sl_stop. Also have many xprint, xprintf, xsprintf and xsnprintf APIs in the code.
Just to check if this works both with debugger and by flashing it to SFLASH. Have you tried this already?
Best regards,
Naveen
Hi Naveen,
good suggestion, scaled it down from 9 to 5 tasks (SLSpawn, Idle, Timers, IPstack and console) all worked fine.
then 1 by 1 added sensors (x2) then Actuators all still fine. Then added Exosite, and it crashed, which is not the same symptom as before.
Previously all would continue running but the IP stack state machine would stop on MAC layer initialization, and the IPLevel connection would not get completed.
Will swop some tasks ie sensors out and bring Exosite back in, see if this makes a difference.
Hi Andre,
I am closing the thread, if issue still exist please open a new thread and add a link to this one for reference.
Best regards,
Naveen