CC3120MOD: Stopping continuous TX with sl_Close()

Hi Ilian,

What SDK and ServicePack do you use?

My CC3220 firmware have testing mode for production RF tests. I had experienced similar as you issue with continuous mode. I had abort error (-2005) when was no delay between closing and opening new socket. Delay between close and reopening socket (about 200-500ms) dramatically improved situation. But abort error sometimes still occurs. In this case I restart NWP.

Jan

Hi Jan,

thank you for your answer.

simplelink_sdk_wifi_plugin_2_40_00_22

simplelink_cc13x2_26x2_sdk_4_10_00_78

I will add this delay, but I receive an error, when I try to stop continuous transmission.

Best regards,

Ilian

Hi Ilian,

And what ServicePack do you have inside your CC3120MOD? Maybe you can try to use latest ServicePack which you find inside CC32xx SDK (yes CC3220 ServicePack is designed for CC3120 as well).

Jan

Hi,

the module is like it is from factory.

Not reprogrammed.

Ilian

Hi Ilian,

Usage CC3120MOD without updated ServicePack is not a best idea.

• at first step please try to update ServicePack and repeat your tests
• if will be issue persistent with latest ServicePack it will be needed capture NWP log or even MAC log. How to capture NWP log is described here at chapter 20. Because I don't have tool for decoding NWP log, you will need to wait for answer from TI.

btw... I remember a little that I discussed similar issue with some other forum user (CC32xx device + some RF test mode + closing socket). I remember that I was not able simulate this problem, but I can't say how it ended. Unfortunately I am not able find that thread now.

Jan

Hi Jan,

I will update the ServicePack and will update you.

Is it possible to take last ServicePak, without to download the last SDK 32XX

Best regards,

Ilian 

Hi Ilian,

No. Latest Service Pack for CC3110 and CC3220 you find inside CC32xx SDK. Inside this SDK you find latest host driver as well for (CC3220, CC3235, CC3230, CC3120, CC3135).

Jan

Hi,

Thanks,

The ServicePak is also available in wi-fi plugin in directori:

C:\ti\simplelink_sdk_wifi_plugin_2_40_00_22\tools\cc31xx_tools\servicepack-cc3x20

Should be the same, if I download the latets wi-fi plugin or latest SDK31xx is better?

Best regards,

Ilian

Hi,

I program one time the last image, but after that I can not connect already with cc3120MOD.

Error: SLImageCreator.exe, BootLoaderError.

I use UART and CC31XXEMUBOOST for programming.

nHIB of the EMUBOOST is connected to nRESET (which is pulled high)

Best regards,

Ilian  

Hi Jan,

the latest ServicePakck did not solve the problem.

Best regards,

Ilian

Hi Ilian,

In this case please capture NWP log (see description at SWRU455 linked above).

Jan

Hi Jan,

I will try.

One more question.

I can make workaround, using for example 10 000 number of packets. And when the transmission stop to close the socket

After that change the channel. For this reason I need to know that the transmission is finished. Is there in this mode interrupt event (callback), which can be used for this purpose?

Best regards,

Ilian

Hi Ilian,

I am not aware about any reasonable way how signalise via event end of the continuous mode transmission. You can to wait for answer from TI, but I don't expect positive answer in this case.

Jan

Hi,

according to the log. CC3120MOD is connected to cc1352R on custom board.

According to the document PIN 62. The expenation in the document is for CC32XX.

Ilian

Hi Ilian,

You can capture NWP log via pin 52 on CC3120MOD or pin 62 at QFN.

Jan

Hi,

unfortunately I can not touch pin 52 (TEST_62) on the custom board.

Ilian

Hi,

If instead of sl_Close I use sl_Stop to stop (power off NWP) until it transmitting and after that sl_Start and open socket on new channel is this will be a problem for NWP?

Ilian

Hi Ilian,

unfortunately I can not touch pin 52 (TEST_62) on the custom board.

I am not sure if some other pin can be used for NWP log at CC3120. At CC3220 can be NWP log pin remapped, but I think this is not possible at CC3120.

If instead of sl_Close I use sl_Stop to stop (power off NWP) until it transmitting and after that sl_Start and open socket on new channel is this will be a problem for NWP?

I don't think so. I think only issue will be delay introduced by NWP restart. If this delay is not important for you, that approach may to be reasonable workaround. But it will be better call sl_Stop with timeout (e.g. 200).

Jan

Hi,

yes I use timeout for sl_Stop, but event with timeout sl_Stop return error -2005, when continuous TX is enabled.

This the code, which I use for TX:

void wifiTxPacketForeverTRCmode(unsigned char *data, _i16 socket, _i16 channel, SlWlanRateIndex_e data_rate)
{
    /* Base frame: */
    #define FRAME_TYPE 0x88
    #define FRAME_CONTROL 0x00
    #define DURATION 0xc0,0x00
    #define RECEIVE_ADDR 0x08, 0x00, 0x28, 0x5A, 0x72, 0x3C
    #define TRANSMITTER_ADDR 0x08, 0x00, 0x28, 0x5a, 0x78, 0x1e
    #define BSSID_ADDR 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF
    #define FRAME_NUMBER 0x00, 0x00
    #define QOS_CTRL 0x00, 0x00

    _i32 NumOfBytes = 0;
    //_i32 Soc = 0;
    _i16 Status = 0;
    _u32 numFrames = 0;

    /* Mac header */
    char buff[500];
    char FrameBaseData[] = {
    FRAME_TYPE,                 /* version, type sub type */
    FRAME_CONTROL,              /* Frame control flag */
    DURATION,                   /* duration */
    RECEIVE_ADDR,               /* Receiver ADDr */
    TRANSMITTER_ADDR,           /* Transmitter Address */
    BSSID_ADDR,                 /* destination */
    FRAME_NUMBER,               /* Frame number */
    QOS_CTRL};                  /* Transmitter */

    memcpy(buff,FrameBaseData,sizeof(FrameBaseData));

    // Example data.
    memcpy (buff + sizeof(FrameBaseData), data, sizeof(buff ) - sizeof(FrameBaseData));

    // Set infinite number frames to transmit - transmit forever.
    Status = sl_SetSockOpt(socket, SL_SOL_PHY_OPT, SL_SO_PHY_NUM_FRAMES_TO_TX, &numFrames, sizeof(numFrames));

    NumOfBytes = sl_Send(socket, buff, sizeof(buff), SL_WLAN_RAW_RF_TX_PARAMS(channel, data_rate, 1, SL_WLAN_LONG_PREAMBLE));
}

Hi,

This is interesting that you see abort error in case of calling sl_Stop(). My continuous mode start code is similar to yours, but I don't see such issue. One thing what we can try else, is to update SimpleLink/Host driver. Latest host driver you find at CC32xx SDK and you can copy driver files over your driver from plug-in 2.4.

If update of driver will not solve issue, then will be needed to capture NWP log somehow.

Jan

Hi,

is it necessary to rebuild the plug-in for new simplelink.a file?

Can you please describe what you mean exactly ti update host driver?

Ilian 

Hi Ilian,

In case you are using pre-compiler library, you will need to re-build library for your host platform.

Jan

Hi,

I work with wi-fi plugin and simplelink.a file. Is there other solution? May be I missed something.

Ilian 

Hi Ilian,

If you don't want to recompile library, you can remove simplelink.a library from your project and copy into your project host driver files, but do not rewrite low level SPI driver (subdirectory porting).

Btw... here is nice guide how to update host driver.

Jan

Hi,

What SP are you using?

Are you based on RadioTool software? (https://www.ti.com/tool/CC3XXXRADIOTEST)

Can you try with less than 10000 packets? can you use the packetized interface instead?

Does other use-case (not RF testing related) works for you? (I'm trying to eliminate porting issues)

Br,

Kobi

Hi Kobi,

I use the latest ServicePack. (from latest CC32XX SDK).

I do not use Radio Tool.

I use function in my application (running on CC1352R) to put the NWP in test mode (transceiver mode) for test purposes - EMC testing.

Yes, I try with 1, 100, 1000, 10000 packets and if I close socket after transmission of the packets finish it work.

The problem exist, when infinite transmission is set. (numFrames = 0)

// Set infinite number frames to transmit - transmit forever.
Status = sl_SetSockOpt(Soc, SL_SOL_PHY_OPT, SL_SO_PHY_NUM_FRAMES_TO_TX, &numFrames, sizeof(numFrames));

I am also afraid to make update or change the plug to not destroy the project.

The idea is pressing the button to change the TX channel and bit rate.

If I do not use infinite TX I try to find some case to understand that the transmission of the packets is finish.

Best regards,

Ilian

I will try this next week. If it gets reproduced (with RadioTool), I would like to check the reason for the (at least) the sl_Stop failure.

I'm not sure how this can happen.

You can also try to debug the call and see what causes this return code.

Hi,

will debug now to see where it return the error code.

It seems like the interface not work.

Ilian

ok, thanks.

I'll check these issues next week.

br,

Kobi

Hi,

here is the screenshot from where the return value is -2005

The code exit after line218, when problem exist.

executing the code in line 218 the error - 2005 is return on line 917 on driver.c file.

When there is no problem RetVal = _SlDrvMsgReadCmdCtx(pCmdCtrl->Opcode, IsLockRequired); /* will free global lock */

RetVal is 0 and sl_Close return 0.

When there is a problem this line return -2005 and it  is returned from sl_Close

Best regards,

Ilian

Hi,

here is the screenshot from where the return value is -2005

The code exit after line218, when problem exist.

executing the code in line 218 the error - 2005 is return on line 917 on driver.c file.

When there is no problem RetVal = _SlDrvMsgReadCmdCtx(pCmdCtrl->Opcode, IsLockRequired); /* will free global lock */

RetVal is 0 and sl_Close return 0.

When there is a problem this line return -2005 and it  is returned from sl_Close

More deeply:

After line 917 , the code go to line 1878

RetVal = _SlDrvMsgRead(&outMsgLen,&pAsyncBuf);

enter here, after some SPI communication (may be there is a problem)

this return -2005

Best regards,

Ilian

Hi Thanks,

in device.h there is no definition SYNC_PATTERN_TIMEOUT_IN_MSEC

Best regards,

Ilian

driver.h

Hi,

I change it to 500, but the problem still exist.

(I change but without to recompile the wi-fi plugin)

Best regards,

Ilian

Hi Kobi,

I found work around in the main application. I send packets and when they finish (after timeout) I send it again.

I have one additional question about IP acquisition in DHCP.

Our device is very low power and IP acquisition time is critical for the current consumption.

For tested AP up to now it let say acceptable. Tested AP - D-Link, TP link.

There is one brand "MICROTIK"  with which the NWP acquire IP for about 6sec. Which is too long time for us.

Questions:

1. I use 'DHCP_FAST_RENEW_WAIT_ACK" ()  setting for IP acquire. If I do not wait for ACK the time will be less. (We only transmit and after transmission the NWP is in HIB state).

Is setting 'no wait for ack' will work better in this case? Is there any potential problems if I use this setting.

2. Is there any way, any settings in AP (Wi-Fi Router DHCP server). which can help to decrease IP acquisition time?

Best regards,

Ilian