CCS/CC2640R2F: YFV (WCSP): BLE5 Simple Peripheral firmware runs on custom board outside debugger, but not in debug

Hi Tony,

The behavior you've described looks like the opposite of this relevant E2E thread.  I'm looping in a BLE expert to further investigate.

Regards,
Ryan 

Tony,

Thank you for reaching out. I've read your post and I need to investigate.

Do you have any LaunchPad available? You can use it as a debugger on your hardware. May be worth trying.

-Luis

Thanks, Luis.  We do have a LaunchPadXL, and will look into how we might get the Tag-Connect hooked up to it.

Tony,

Do you mind sharing what exact Launch Pad you have? We need to check if the debugger part is functional with the CC2640R2 chip.

I think that trying with other debuggers should be a priority.

Also, regarding the case when it works (not running the debugger), are you using the same Segger debugger to load the hex file?

-Luis

We have the LAUNCHXL CC2640R2.

I have been downloading the firmware to the device using the CCS v10 debug environment.  The debug configuration for the project specifies the SEGGER J-Link Emulator as the connection.  There have been no problems downloading firmware and initiating a debug session.  It just usually falls into ICall_Abort() on starting execution.  After exiting the debugger and cycling power on the device, the device is running.

Below is the connection configuration from CC2640R2F.ccxml.  The JTAG Frequency is set to auto.  Might setting that to a specific value help?

Are you suggesting that the results could be different if we use a TI debug probe vs. the J-Link?  The only concern there is a compatible connection from an alternate debug adapter to the Tag-Connect 6-pin board edge connector.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<configurations XML_version="1.2" id="configurations_0">
<configuration XML_version="1.2" id="SEGGER J-Link Emulator_0">
        <instance XML_version="1.2" desc="SEGGER J-Link Emulator_0" href="connections/segger_j-link_connection.xml" id="SEGGER J-Link Emulator_0" xml="segger_j-link_connection.xml" xmlpath="connections"/>
        <connection XML_version="1.2" id="SEGGER J-Link Emulator_0">
            <instance XML_version="1.2" href="drivers/JLINKicepick_c.xml" id="drivers" xml="JLINKicepick_c.xml" xmlpath="drivers"/>
            <instance XML_version="1.2" href="drivers/jlinkcs_dap.xml" id="drivers" xml="jlinkcs_dap.xml" xmlpath="drivers"/>
            <instance XML_version="1.2" href="drivers/jlinkcortexm3.xml" id="drivers" xml="jlinkcortexm3.xml" xmlpath="drivers"/>
            <platform XML_version="1.2" id="platform_0">
                <instance XML_version="1.2" desc="CC2640R2F_0" href="devices/cc2640r2f.xml" id="CC2640R2F_0" xml="cc2640r2f.xml" xmlpath="devices"/>
            <device HW_revision="1" XML_version="1.2" description="SimpleLink(TM) Bluetooth(R) low energy CC2640R2F wireless MCU" id="CC2640R2F_0" partnum="CC2640R2F">
                    <router HW_revision="1.0" XML_version="1.2" description="ICEPick_C Router" id="IcePick_C_0" isa="ICEPICK_C">
                        <subpath id="subpath_0">
                            <router HW_revision="1.0" XML_version="1.2" description="CS_DAP Router" id="CS_DAP_0" isa="CS_DAP">
                                <subpath id="subpath_1">
                                    <cpu HW_revision="1.0" XML_version="1.2" description="Cortex_M3 CPU" id="Cortex_M3_0" isa="Cortex_M3">
                                        <property Type="choicelist" Value="2" id="Target Interface Type"/>
                                    </cpu>
                                </subpath>
                            </router>
                        </subpath>
                    </router>
                </device>
            </platform>
        </connection>
    </configuration>
</configurations>

Tony,

It's great that you have a CC2640R2 LaunchPad. Yes, I believe that we could get different results using the TI debugger.

I'm sure there could be some hw or sw setting on the Segger that we might be missing or incorrect. If it always fails during initialization, it feels as if something is not being loaded properly, not necessarily an error with JTAG frequency. However, it may be worth trying to set it manually. 

The biggest IC on your LaunchPad is the debugger. So, you need to remove the jumpers that connect the top part (i.e. closest to the USB connector) from the bottom part (i.e. farthest from the USB connector). Please look at the section "Advanced use of the LaunchPad hardware" from the product's page. As you mentioned, there might be a challenge in adapting the debugger connections to your target.

Would you please give it a try? In the meantime I will investigate what else could be wrong with the Segger settings. By the way, it may be worth contacting them with your issue, too.

-Luis

Luis M said:

it may be worth contacting [Segger] with your issue, too.

That occurred to me.  I'll give that a go.

I have passed the info on using the launchpad as a debug probe on to the hardware engineer.  We'll look into getting the Tag-Connect hooked up to the LaunchPad.

Tony,

Awesome. I'll continue investigating on my side.

-Luis

Hi,

   I suspect you might be experiencing a hang. Debug step you code and make sure you are able to pass Simple Peripheral Init().

   When you modify the Simple Peripheral to work for your custom board, you need to comment this out, that is if you do not have a SPI External Flash connected to those exact SPI pins.

CC2640R2_LAUNCHXL_fxns.c

/*
* ======== Board_initHook ========
* Called by Board_init() to perform board-specific initialization.
*/
void Board_initHook()
{
CC2640R2_LAUNCHXL_shutDownExtFlash();
}

=kel

Tony, 

Do you have any updates? Were you able to run with our LaunchPad debugger?

Also, did you get any inputs from Segger?

I had a couple of suggestions:

• Try to reproduce the issue on a LaunchPad, using the Segger JLink. As I have mentioned before, you can isolate the CC2640R2 from the "debugger" side of the LaunchPad.
• Try to modify your code, to see if this is an issue with function GAP_SetParamValue() or any of the functions it invokes, or with "timing". So for example, you could add a for loop before that section of the code; or start eliminating parts of the code (with #ifdef 0 {} #endif) to see if it is a particular part of the code that fails.
• As Markel suggested, this could be related to a component that you don't have on your board, like an external flash. Please re-review your Board Migration Guide.

Looking forward to hear from you.

-Luis

Some updates:

In the course of investigating an issue with our application, I ran the custom firmware on the Launchpad, and did not have any issues with Bluetooth functionality when running in debug.

The issue we were looking into involved the SPI interface to a couple sensors, and I was able to place this code before executing the GSS_SetParameter call and debug the issue using the Segger adapter (BLE comm was not needed).  Not sure why today it is not getting past GSS_SetParameter to GAP_SetParamValue.

Since I have to use the Launchpad for testing related to this product and other products, we decided to order an XDS110 debug probe rather than keep removing and replacing the row of jumpers.  Plus getting the XDS110 hooked up the TagConnect is a little more straightforward hardware-wise.  This should arrive early next week.

Regarding the interface to external flash, the call to [boardname]_shutDownExtFlash in Board_initHook() was commented out early on prior to starting testing.  The product does have external flash, but we are using the SPI driver to communicate with it.

Execution in debug does not return from SimplePeripheral_init() as the call to GSS_SetParamValue is part of this function, and this where it falls into ICall_abort.

The JLink only came with one 20-pin to 20-pin ribbon cable, so the hardware engineer would have a similar challenge connecting the JLink to the Launchpad as connecting the Lauchpad to the TagConnect for the custom board (unless we could locate and purchase a cable).  We will stand by for the XDS110 to get here and report results.

I got wrapped up in another issue and did not contact Segger.  I just submitted an issue to their support site a few minutes ago.

Execution goes from SimplePeripheral_init, into GGS_SetParameter(GGS_DEVICE_NAME_ATT, GAP_DEVICE_NAME_LEN, attDeviceName), where it makes it through the call to ICall_sendServiceMsg, but then returns a timeout error from ICall_waitMatch.  I am not able to step through that function.  Since the timeout specified in the call to ICall_waitMatch is 5 seconds, I'm assuming that increasing that value is not going to help.  ICall_waitMatch is returning a timeout error, so it is not clear where to place for loops in order to tweak timing of the operation initiated by the call to ICall_sendServiceMsg.

I just ran through some alternate connection speeds, and oddly, when changing back from a specific speed that did not work to auto, it has worked a few times.  I have not been able to find what the optimal JTAG frequency is for this CC2640R2 variant, but have read values from 1/8 to 1/6 of the ARM core's speed should work.  No specific values in that range worked.  When set to auto, the actual connection speed is 4 MHz.  I have tried various values around 4 MHz, but none work consistently.  (4.1 MHz and 4.5 MHz worked one time each)

Thanks again.

Tony K.

Tony Kobet said:

The issue we were looking into involved the SPI interface to a couple sensors, and I was able to place this code before executing the GSS_SetParameter call and debug the issue using the Segger adapter (BLE comm was not needed).  Not sure why today it is not getting past GSS_SetParameter to GAP_SetParamValue.

So, you are experiencing a hang. The first thing I do working with smaller CC2640R2F is that I modify the simple peripheral to work with it.  I test the simple peripheral and make sure it works as expected Then I add code specific to my application. After adding code and the simple peripheral encounter issues, I know my added code caused it.

Tony Kobet said:

Since I have to use the Launchpad for testing related to this product and other products, we decided to order an XDS110 debug probe rather than keep removing and replacing the row of jumpers.

I use Launchpad for debugging and programming custom boards, for the reason that is cheaper than buying a XDS110 debug probe. I have 2 Launchpad dedicated for debugging and programming purposes.

Tony Kobet said:

Execution goes from SimplePeripheral_init, into GGS_SetParameter(GGS_DEVICE_NAME_ATT, GAP_DEVICE_NAME_LEN, attDeviceName), where it makes it through the call to ICall_sendServiceMsg, but then returns a timeout error from ICall_waitMatch.  I am not able to step through that function.

Share your SimplePeripheral_init() code for review.

-kel

Markel Robregado said:

The first thing I do working with smaller CC2640R2F is that I modify the simple peripheral to work with it.  I test the simple peripheral and make sure it works as expected Then I add code specific to my application.

This is the approach I took as well.  The debug configuration has not worked, or has worked rarely, from that initial phase onward, but has always worked outside of debug.

Markel Robregado said:

I use Launchpad for debugging and programming custom boards, for the reason that is cheaper than buying a XDS110 debug probe.

That's a good point.  I think the issue was with creating a physical connection to the TagConnect rather than cost.

SimplePeripheral_init() follows.  (call to HCI_EXT_SetSCACmd is commented out here since it is executed at the beginning of RCOSC_enableCalibration)

static void SimplePeripheral_init(void)
{
  // ******************************************************************
  // N0 STACK API CALLS CAN OCCUR BEFORE THIS CALL TO ICall_registerApp
  // ******************************************************************
  // Register the current thread as an ICall dispatcher application
  // so that the application can send and receive messages.
  ICall_registerApp(&selfEntity, &syncEvent);

//HCI_EXT_SetSCACmd(500);

#ifdef USE_RCOSC
  RCOSC_enableCalibration();
#endif // USE_RCOSC

  // Create an RTOS queue for message from profile to be sent to app.
  appMsgQueueHandle = Util_constructQueue(&appMsgQueue);

  // Create one-shot clock for internal periodic events.
  Util_constructClock(&clkPeriodic, SimplePeripheral_clockHandler,
                      SP_PERIODIC_EVT_PERIOD, 0, false, (UArg)&argPeriodic);

  // Set the Device Name characteristic in the GAP GATT Service
  // For more information, see the section in the User's Guide:
  // http://software-dl.ti.com/lprf/ble5stack-latest/
  GGS_SetParameter(GGS_DEVICE_NAME_ATT, GAP_DEVICE_NAME_LEN, attDeviceName);

  // Configure GAP
  {
    uint16_t paramUpdateDecision = DEFAULT_PARAM_UPDATE_REQ_DECISION;

    // Pass all parameter update requests to the app for it to decide
    GAP_SetParamValue(GAP_PARAM_LINK_UPDATE_DECISION, paramUpdateDecision);
  }

#if defined(GAP_BOND_MGR)
  // Setup the GAP Bond Manager. For more information see the GAP Bond Manager
  // section in the User's Guide:
  // http://software-dl.ti.com/lprf/ble5stack-latest/
  {
    // Don't send a pairing request after connecting; the peer device must
    // initiate pairing
    uint8_t pairMode = GAPBOND_PAIRING_MODE_WAIT_FOR_REQ;
    // Use authenticated pairing: require passcode.
    uint8_t mitm = TRUE;
    // This device only has display capabilities. Therefore, it will display the
    // passcode during pairing. However, since the default passcode is being
    // used, there is no need to display anything.
    uint8_t ioCap = GAPBOND_IO_CAP_DISPLAY_ONLY;
    // Request bonding (storing long-term keys for re-encryption upon subsequent
    // connections without repairing)
    uint8_t bonding = TRUE;

    GAPBondMgr_SetParameter(GAPBOND_PAIRING_MODE, sizeof(uint8_t), &pairMode);
    GAPBondMgr_SetParameter(GAPBOND_MITM_PROTECTION, sizeof(uint8_t), &mitm);
    GAPBondMgr_SetParameter(GAPBOND_IO_CAPABILITIES, sizeof(uint8_t), &ioCap);
    GAPBondMgr_SetParameter(GAPBOND_BONDING_ENABLED, sizeof(uint8_t), &bonding);
  }
#endif

  // Initialize GATT attributes
  GGS_AddService(GATT_ALL_SERVICES);           // GAP GATT Service
  GATTServApp_AddService(GATT_ALL_SERVICES);   // GATT Service
  DevInfo_AddService();                        // Device Information Service

  SimpleProfile_AddService(GATT_ALL_SERVICES); // Simple GATT Profile

  // Setup the SimpleProfile Characteristic Values
  // For more information, see the GATT and GATTServApp sections in the User's Guide:
  // http://software-dl.ti.com/lprf/ble5stack-latest/
  {
    uint8_t charValue1 = 1;
    uint8_t charValue2 = 2;
    uint8_t charValue3 = 3;
    uint8_t charValue4 = 4;
    uint8_t charValue5[SIMPLEPROFILE_CHAR5_LEN] = { 1, 2, 3, 4, 5 };

    SimpleProfile_SetParameter(SIMPLEPROFILE_CHAR1, sizeof(uint8_t),
                               &charValue1);
    SimpleProfile_SetParameter(SIMPLEPROFILE_CHAR2, sizeof(uint8_t),
                               &charValue2);
    SimpleProfile_SetParameter(SIMPLEPROFILE_CHAR3, sizeof(uint8_t),
                               &charValue3);
    SimpleProfile_SetParameter(SIMPLEPROFILE_CHAR4, sizeof(uint8_t),
                               &charValue4);
    SimpleProfile_SetParameter(SIMPLEPROFILE_CHAR5, SIMPLEPROFILE_CHAR5_LEN,
                               charValue5);
  }

  // Register callback with SimpleGATTprofile
  SimpleProfile_RegisterAppCBs(&SimplePeripheral_simpleProfileCBs);

#if defined(GAP_BOND_MGR)
  // Start Bond Manager and register callback
  VOID GAPBondMgr_Register(&SimplePeripheral_BondMgrCBs);
#endif

  // Register with GAP for HCI/Host messages. This is needed to receive HCI
  // events. For more information, see the HCI section in the User's Guide:
  // http://software-dl.ti.com/lprf/ble5stack-latest/
  GAP_RegisterForMsgs(selfEntity);

  // Register for GATT local events and ATT Responses pending for transmission
  GATT_RegisterForMsgs(selfEntity);

  // Set default values for Data Length Extension
  // Extended Data Length Feature is already enabled by default
  {
    // Set initial values to maximum, RX is set to max. by default(251 octets, 2120us)
    // Some brand smartphone is essentially needing 251/2120, so we set them here.
    #define APP_SUGGESTED_PDU_SIZE 251 //default is 27 octets(TX)
    #define APP_SUGGESTED_TX_TIME 2120 //default is 328us(TX)

    // This API is documented in hci.h
    // See the LE Data Length Extension section in the BLE5-Stack User's Guide for information on using this command:
    // http://software-dl.ti.com/lprf/ble5stack-latest/
    HCI_LE_WriteSuggestedDefaultDataLenCmd(APP_SUGGESTED_PDU_SIZE, APP_SUGGESTED_TX_TIME);
  }

  // Initialize GATT Client
  GATT_InitClient();

  // Init key debouncer
//Board_initKeys(SimplePeripheral_keyChangeHandler);

  // Initialize Connection List
  SimplePeripheral_clearConnListEntry(CONNHANDLE_ALL);

  //Initialize GAP layer for Peripheral role and register to receive GAP events
  GAP_DeviceInit(GAP_PROFILE_PERIPHERAL, selfEntity, addrMode, NULL);

  // Initialize array to store connection handle and RSSI values
  SimplePeripheral_initPHYRSSIArray();

  // The type of display is configured based on the BOARD_DISPLAY_USE...
  // preprocessor definitions
//dispHandle = Display_open(Display_Type_ANY, NULL);
}

Heard back from Segger.  The engineer that responded suspects an issue within the BLE stack related to low-power modes, debug clocks, etc.  They would be happy to assist further for a nominal fee (refundable if it is a Segger issue).

We received the XDS110 debug probe, and the hardware engineer was able to adapt the XDS110 ribbon cable to the 6-pin connection at the TagConnect.  I am not seeing any issues with debugging our board with this configuration.  I have started/stopped a half-dozen debug sessions, paused/resumed, and BLE communication works fine.  No calls to ICall_Abort.

I suspect some issue within Segger's emulator.  Since we are debugging fine with the XDS110, I'm not sure it's productive to try to figure out why it will not work using the J-Link.  We are content to set the J-Link aside and continue development on this product with the TI debug probe.