CC3235MODSF: Stuck at sl_stop after upgrade to sdk 3_30_00_04

Cedric Gerber

Part Number: CC3235MODSF

Hi,

With the lastest sdk, when my cc3235 project is build on linux, it hangs at the first sl_stop.

I have two projects, one with a cc3235modsf and one with a cc3220modasf.

Both can be compiled either on my windows computer or on a raspberrypi in an ubuntu docker container by our continuous integration server.

I have upgraded both products to the latest sdk 3_30_00_04 and service pack (sp_4.4.0.3_3.1.0.5_3.1.0.19 and sp_3.13.0.3_2.0.0.0_2.2.0.6).

Since then the project with the cc3235 gets stuck at the first sl_stop when built on linux. When built on windows it's ok. And the project with the cc3220 is ok on both.

The code is mostly identical between both project.

The issue is present with both ccs9.1/compiler 18.12.2 and ccs9.2/compiler 18.12.3.

With the previous sdk (3_20_01_01) but latest service pack it is ok.

Any idea on what could be the issue?

Do not hesitate to ask for any information!

Best regards,

Cédric

over 4 years ago

0 Kobi Leibovitch over 4 years ago

TI__Guru 61636 points

Hi Cedric,

Just to make sure I understand.

You use the same CCS and toolchain versions to compile the same CC3235 code on both environments and get different MCU image binaries. Using the latest SP - the window's build works but the Linux one fails.

What is the difference between your CC3220 and CC3235 code?

What happens if you just replace the SP to a previous working one (without changing the MCU image)?

br,

Kobi

0 Cedric Gerber over 4 years ago in reply to Kobi Leibovitch

Expert 2240 points

Hi Kobi,

You understood correctly.

The cc3220 and cc3235 code is for two different products, so they are for instance handling different gpio and i2c devices and with a different sequence, but the whole interface to the nwp is basically the same (same configuration, same calls of all functions, ...). The main difference from the point of view of the nwp will be the timing of the calls.

When reverting only the SP, there is the issue.

When reverting only the sdk, it is ok.

Thanks for your help!

Cédric

0 Kobi Leibovitch over 4 years ago in reply to Cedric Gerber

TI__Guru 61636 points

Hi Cedric,

This is very strange.

What exactly happens when the sl_Stop hangs? Can you check the status of the program using the debugger?

Do you get any error event?

What are you doing before the call to sl_Stop?

Br,

Kobi

0 Cedric Gerber over 4 years ago in reply to Kobi Leibovitch

Expert 2240 points

Hi Kobi,

Found it \o/

I just tried with the last sdk_3_30_01_02 and sp_4.4.1.3_3.1.0.5_3.1.0.19, same thing.

I don't see any error event, but I might miss some as my ti-rtos + system_print seem to have some issue in case of fatal errors.

Regarding the location, I've just tried to add a sl_stop at a few places in my code and can pinpoint it to right after the i2c init:

    I2C_init();

    /* Create I2C for usage */
    I2C_Params_init(&i2cParams);
    i2cParams.bitRate = I2C_100kHz;
    i2cParams.transferMode = I2C_MODE_BLOCKING;

    i2c = I2C_open(Board_I2C_TMP, &i2cParams);
    if (i2c == NULL)
    {
        ERROR_PRINT("I2C Init");
        return -1;
    }

The i2c is configured as:

const I2CCC32XX_HWAttrsV1 i2cCC3220SHWAttrs[CC3220SF_LAUNCHXL_I2CCOUNT] = {
    {
        .baseAddr = I2CA0_BASE,
        .intNum = INT_I2CA0,
        .intPriority = (~0),
        .clkPin = I2CCC32XX_PIN_16_I2C_SCL,
        .dataPin = I2CCC32XX_PIN_17_I2C_SDA
    }
};

Then I realized I had a custom version of the file I2CCC32XX.c in my project, but I've excluded it from the build so assumed it had no impact. I tried to remove it together with its header I2CCC32XX.h and voilà it works ; )

Since I have the exact same thing in my cc3220 project, I'm not sure why it works there.

I suppose the project is either imported a little differently in my linux build. I'll have to investiguate...

Thanks.

Best regards,

Cédric

Wi-Fi

Wi-Fi forum

CC3235MODSF: Stuck at sl_stop after upgrade to sdk 3_30_00_04