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.

Code semi working from flash but 100% from debugger

Other Parts Discussed in Thread: CC3200I am having a consistent problem getting an application to run from flash. Background is as follows. # Using SDK 1.0.0 on CC3200 LP3.1. # Application using 9 tasks under FreeRTOS 8.1.2 # All tasks start perfectly, and the Console task displays the task status with run counters # My SimpleLink task starts a state engine to initialize WL MAC layer, then IP, then NTP, sockets etc # Other tasks read sensors, task to Exosite etc... Running under debug, it runs perfectly, starts all tasks, brings up ALL levels on the comms state machine, connect to Exosite (last stage on comms state, and logs data perfectly for hours. I can restart it 20 times and 20 times it will come up perfectly. When I flash the binary and monitor the status, all tasks except start and continue functioning normally, other than the comms state machine and as a result Exosite. The comms state machine stays on the MAC initialization stage and gets no further. does not connect to AP or anything further. As a result the Exosite task sits and wait for the comms state to get to the level where it can continue but never gets there. Whether I give the comms task a FreeRTOS scheduling interval of 100mS, 500mS or 1000mS between checks fir a change in status, no difference. Only indicator that gives me a hint is that the SLSPAWN task uses no ticks, indicating that no events are queued to this task. And running back again (exact same code) under the debugger it runs 100% perfect, hence I cannot debug something I cannot make happen. Any suggestions, I have run out of ideas? André
  • 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