• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 40 subscribers
  • Views 2024 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

cc3200 sl_Start() does not return when using the debugger

Ignisuti
Intellectual 655 points
Other Parts Discussed in Thread: SEGGER, CC3200

Using GCC via Eclipse Mars 2 on Windows 7 64-bit system

Debugger is a Segger J-Link using 2-Wire debug.

OS: FreeRTOS

SDK: 1.2.0

 

I've seen this issue posted multiple times already in the forum, but none of those solutions work for us.

The problem is that we're calling ConfigureSimpleLinkToDefaultState() in our main task and it calls sl_Start( 0, 0, 0 ) which never returns. If we click the debugger's reset button at the top of Eclipse and try again it works. Each time we reset, it toggles between a working and non-working state. We only see the issue while using the debugger, but it's a constant nuisance to our development team.

Please help us understand and resolve this issue.

  • 0
    Guru 39650 points

    Hi,

    Sorry I am cruel but I need to laugh. At previous post you say that all works with your Eclipse. But now you saying that something not work. If you decided use solution which is not supported by manufacturer, you can expect that something should not work.

    My suggestion:
    - use 4 wire JTAG
    - follow this thread and build SimpleLink library with OS_debug e2e.ti.com/.../1806610

    Jan

  • 0 in reply to Hnz
    Intellectual 655 points
    We've already seen the OS_debug option. In our opinion, compiling, testing, and debugging with code that won't be in the final product is not an acceptable solution.

    Since the example code includes makefiles and startup code for GCC, I think it's safe to say TI has made an attempt to support the path we've taken.

    There is a distinction between IDE and SDK. In the former post that you're referring to, I'm indicating that all works well with the IDE. The SDK , specifically Simplelink, is presenting the problem detailed in this post. I did however forget to mention that we had this same issue with Simplelink when trialing CCS and IAR with various debuggers. So, the problem appears to be either with our implementation or the SDK itself. That is why I'm here on the TI forum requesting guidance. I'm confident that we can fix it ourselves in the code, but if there's anyone out there that can give us guidance, it would be a very welcomed head-start.
  • 0 in reply to Ignisuti
    Guru 39650 points

    Hi,

    If proper, official and functional solution is not acceptable for you, then I am not able to help you. If you will better study difference between "OS" and "OS debug" build configuration, you will see the difference is very small (DISABLE_DEBUGGER_RECONNECT). Different is only small part on NWP init section. I think there is nothing you should afraid.

    A agree with you, that SimpleLink library is not perfect. But it does not exist perfect code. In comparison with competitors Wireless platforms, is SimpleLink not that bad. I think in SimpleLink are bigger issues than you mentioned. Problems which you mentioned are really marginal.

    TI supports for CC3200 two main IDEs (CCS, IAR). Don't ask me why only these two platforms. You can forward this question directly to your TI representative. This is best way how to contact product marketing team.

    It is good to hear that exists companies where resources (IDE) are more important than results (final product). I can imagine that for developer is good to work in this type of company.

    Regards,

    Jan

  • 0 in reply to Hnz
    Intellectual 655 points

    Thanks for the suggestion to look at "DISABLE_DEBUGGER_RECONNECT". That did give us a head-start at solving this problem. By following your suggestion, we experienced a significant start-up delay that averaged around 6 seconds. I think that makes sense now why TI made an attempt to eliminate that delay. 

    Here's the solution we came up with, and our recommendation to TI and other users experiencing this issue.

    Instead of having a #define for DISABLE_DEBUGGER_RECONNECT that is set at design time, it should be replaced with a run-time check to determine whether or not a debugger is connected. That can be done with the following code:

    #define DHCSR_REG                   (*(_u32*)(0xE000EDF0))     /* ARM Cortex Debug Halting Control and Status Register */
#define C_DEBUGEN                   ( 0x00000001 )            /* Debug enabled bit */
#define DEBUG_SESSION_ACTIVE        ( DHCSR_REG & C_DEBUGEN ) /* TRUE if a debug session is active. Note: Does NOT indicate whether debug cable is connected. */

    Once this change is made, NwpPowerOnPreamble() will be called only when the debugger is connected. The developer will receive a 6 second delay, but that's better than having to reset multiple times. Then, when the debugger is not connected, such as in the final customer application, Simplelink will be quick to startup. 

    This isn't the ultimate solution and we expect TI to eventually provide a better solution, but felt this was a decent improvement to the SDK 1.2.0.