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.

RTOS/BLE-STACK: MSP432 SimpleLink Bluetooth Plugin v1.25.00.42 GPIO Issues (plus requested fixes)

Part Number: BLE-STACK

Tool/software: TI-RTOS

Hi,

I'm in the process of updating my firmware from SimpleLink MSP432 SDK 1.40.01.00 and Bluetooth Plugin 1.20.00.42 to 1.60.00.12 and 1.25.00.42 respectively and have noticed a breaking change in the code. The updated MSP432 SDK validates more settings in the GPIO driver and in particular it validates that you only try to set a pin's drive strength if it is supported. Good idea, I like it. However, in the Bluetooth plugin we have the following GPIO configuration in npi/npi_tl_simplelink.c

static GPIO_PinConfig npiHandshakePinsCfg[] =
{
    GPIO_CFG_INPUT | GPIO_CFG_IN_PU,
    GPIO_CFG_OUT_STD | GPIO_CFG_OUT_HIGH | GPIO_CFG_OUT_STR_HIGH
};

My master ready pin is Port 2.5, and therefore the GPIO_setConfig fails and the BLE plugin cannot control MRDY. I don't know why the GPIO is configured as high strength, but removing it fixes the issue.

I've fixed this myself in my code, but would like this incorporated into a future release so I don't have to build it myself. Additionally, is it possible to fix the following bugs in the next release? 

Final question: does Texas Instruments have any plans to release version controlled repositories for future SDK releases? Currently I have to manually create a Git repo for each of your components (e.g. msp432 sdk, ble-plugin) and then when an update is released, copy new files into the repo and inspect the code for relevant changes. 

Thanks

Campbell

  • Hi Cambell,

    Let me run a couple of tests and I'll get back to you. Also I'm looking into when those bugs are going to be fixed.

    Thanks,

    David
  • Hi Cambell,

    Campbell Young said:
    My master ready pin is Port 2.5, and therefore the GPIO_setConfig fails and the BLE plugin cannot control MRDY. I don't know why the GPIO is configured as high strength, but removing it fixes the issue.

    Unfortunately I have not been able to reproduce this issue, I switched P6.0 to be SRDY and P2.5 to be MRDY and it is working on my side.

    //            sapParams.port.remote.mrdyPinID = Board_MRDY;
    //            sapParams.port.remote.srdyPinID = Board_SRDY;
                sapParams.port.remote.mrdyPinID = Board_SRDY;
                sapParams.port.remote.srdyPinID = Board_MRDY;

    I did not change the gpio configuration in the board file.

        /* MSP_EXP432P401R_SRDY */
        GPIOMSP432_P2_5 | GPIO_CFG_OUT_STD | GPIO_CFG_OUT_STR_HIGH
                | GPIO_CFG_OUT_HIGH,
        /* MSP_EXP432P401R_BL */
        GPIOMSP432_P6_0 | GPIO_CFG_IN_PU,

    Also I created a simple project to change to change the GPIO configuration on the fly.

        GPIO_setConfig(Board_GPIO_TEST,
                       GPIO_CFG_OUT_STD | GPIO_CFG_OUT_HIGH | GPIO_CFG_OUT_STR_HIGH);
    

    and in the board file I have:

        /* MSP_EXP432P401R_GPIO_TEST */
    //    GPIOMSP432_P2_5 | GPIO_CFG_OUT_STD | GPIO_CFG_OUT_STR_HIGH | GPIO_CFG_OUT_LOW,
        GPIOMSP432_P2_5 | GPIO_CFG_INPUT,

    Maybe the way that you are building the library has something to do with this, is this a project you can share with me??

    Campbell Young said:
    Additionally, is it possible to fix the following bugs in the next release? 

    They were not fixed on v1.30, but I'm pushing them to be fixed on v1.40

    Campbell Young said:
    Final question: does Texas Instruments have any plans to release version controlled repositories for future SDK releases?

    Not yet, but I see your point. Let me discuss internally and I'll get back to you.

      Best regards,

        David

  • Hi David,

    Thanks for the reply. What version of the MSP432 SimpleLink SDK are you using? You'll only notice this issue if it's simplelink_msp432p4_sdk_1_60_00_12 or later because the GPIO driver has been updated to check the pin strength constraint. See lines 484-488 in source/ti/drivers/gpio/GPIOMSP432.c, also copied below:

    if (((port != 2) || (pin > 0x04)) &&
                    (pinConfig & GPIO_CFG_OUT_STRENGTH_MASK)) {
                    HwiP_restore(key);
    
                    return (GPIO_STATUS_ERROR);
                }

    So if the pin isn't suitible for GPIO_CFG_OUT_STRENGTH_MASK it will return after configuring the pin for output, but before setting its state to high/low. My pin's default state is low (GPIOMSP432_P2_5 | GPIO_CFG_OUT_OD_NOPULL | GPIO_CFG_OUT_STR_LOW | GPIO_CFG_OUT_LOW), so the call to GPIO_setConfig never sets it to the expected state of GPIO_CFG_OUT_HIGH and as such the CC26xx device has no indication that the master is ready and therefore I cannot communicate with the device. I haven't checked the code, but I guess it waits for a high to low edge before transmitting?

    If you still can't reproduce the issue with a default-low pin state, I'll have a closer look on my end. Also, thanks for trying to get the linked fixes into v1.40 :)

    Cheers

    Campbell

  • Hi Cambell,

    Campbell Young said:
    What version of the MSP432 SimpleLink SDK are you using? You'll only notice this issue if it's simplelink_msp432p4_sdk_1_60_00_12 or later because the GPIO driver has been updated to check the pin strength constraint. See lines 484-488 in source/ti/drivers/gpio/GPIOMSP432.c, also copied below:

    That's the same version that I'm using. And yes you are correct the API will return an error and it will not set the GPIO as HIGH. I was not seeing the issue because I was toggling the GPIO after setting the configuration. But before returning the error it will set the GPIO as an output.

                /* configure output */
                MAP_GPIO_setAsOutputPin(port, pin);
    
                /*
                 * Drive strength is only available on pins 2.0 - 2.3;
                 * return error if trying to configure high drive strength on
                 * other pins.
                 */
                if (((port != 2) || (pin > 0x04)) &&
                    (pinConfig & GPIO_CFG_OUT_STRENGTH_MASK)) {
                    HwiP_restore(key);
    
                    return (GPIO_STATUS_ERROR);
                }

    Anyway I just submitted a bug to remove the GPIO_CFG_OUT_STR_HIGH from the pin configuration.

      Thanks,

       David