CC3100MOD: cc3100MOD and custom board - sl_Get() return API_ABORTED

Here is code snippet:

void wifi_test_func()
{
    sl_Start(NULL,NULL,NULL);

    SlVersionFull         ver;
        _u8                 pConfigOpt, pConfigLen;
    _i32                 retVal = 0;

    /* read the version and print it on terminal */
    pConfigOpt = SL_DEVICE_GENERAL_VERSION;
    pConfigLen = sizeof(SlVersionFull);
    retVal = sl_DevGet(SL_DEVICE_GENERAL_CONFIGURATION,&pConfigOpt,&pConfigLen,(_u8 *)(&ver));

    if(retVal < 0)
    {
        sprintf(printBuffer, "\r\nReading version failed. Error code: %d\r\n", (int)retVal);
        printf("\n%s", printBuffer);
    }

    if (ver.ChipFwAndPhyVersion.ChipId & 0x10)
        printf("\r\nThis is a CC3200");
    else
        printf("\r\nThis is a CC3100");

    if (ver.ChipFwAndPhyVersion.ChipId & 0x2)
        printf("Z device\r\n");
    else
        printf("R device\r\n");

    sprintf(printBuffer, "NWP %d.%d.%d.%d\n\rMAC 31.%d.%d.%d.%d\n\rPHY %d.%d.%d.%d\n\r\n\r", \
            (_u8)ver.NwpVersion[0],(_u8)ver.NwpVersion[1],(_u8)ver.NwpVersion[2],(_u8)ver.NwpVersion[3], \
                 (_u8)ver.ChipFwAndPhyVersion.FwVersion[0],(_u8)ver.ChipFwAndPhyVersion.FwVersion[1], \
                 (_u8)ver.ChipFwAndPhyVersion.FwVersion[2],(_u8)ver.ChipFwAndPhyVersion.FwVersion[3], \
                 ver.ChipFwAndPhyVersion.PhyVersion[0],(_u8)ver.ChipFwAndPhyVersion.PhyVersion[1], \
                 ver.ChipFwAndPhyVersion.PhyVersion[2],(_u8)ver.ChipFwAndPhyVersion.PhyVersion[3]);

    printf("\n%s", printBuffer);

}

Hi,

The code looks OK.

Your understanding is correct regarding the module but it is always a good practice to program the device with the latest servicepack since you don't know what is flashed inside the module.

Can you retry after programming the device?

From getting all 0 for the version and the fact the the role is unknown, it might be that the device is not programmed at all (this is why i asked to reprogram) or that something is wrong with the porting you did for the Kinetis.

• what UART clock and configuration are you using?
• did you apply all porting steps in user.h header file?
• freescale Kinetis usually uses big endian that might pop up an issue although the simplelink driver should cope with it automatically

Next step would be to probe the UART lines and understand what is coming back on the lines.

Regards,

Shlomi

Hi Shlomi,

Thank you for your reply.

Shlomi Itzhak said:

what UART clock and configuration are you using?

- I found in the documentation that two baud rates are in use by default: 921600bps and 115200bps. Currently, I use 921600 bps. When should I use 115200?

Shlomi Itzhak said:

did you apply all porting steps in user.h header file?

- Yes, except porting OS step.

Shlomi Itzhak said:

Can you retry after programming the device?

- I will get back to you after I flash the device.

Hi,

there is no limitation on what baud rate to use. you can always change the rate via an API if the host processor has some limitations but this is not why your use case fails.

Let me know when you reprogram the device.

as I mentioned, if you still experience issues, the best would be to probe the UART lines and inspect what is coming from the chip.

Regards,

Shlomi

Hi,

I try to flash the module. I successfully format 1 MB of the module flash. Now when I called sl_Start() I got a ROLE_AP_ERR error.

I wasn’t able to flash firmware to the module. When I call function sl_FsOpen() I get error code API_ABORTED.

Porting:

- I didn’t include the SOCKET package, NET_CFG package, socket APIs packages

- I use a static memory model

- I implement all communication and interrupt functions. I check those functions:

- Messages between MCU and the module are successfully sent and received.

- IRQ isr is successfully registered and called.

- I didn’t port OS.

Signal diagram for the whole proccess:

The explanation for the diagram:

First MCU TX line is put low. Then the nHib line is pulled high. After that first ACK from the cc3100 module was received.

After ACK is received from the module format command has been sent.

For that command, MCU receive one more ACK after about 1s. After that MCU sends a disconnect message to the module, after which MCU received ACK again.

After this sl_Start() is called and for that, there is a low on the nHib line at around 4.55s.

This is a code snippet:

void wifi_test_func()
{
	cc3100_uart_init();

	enter_bl_mode();
	bl_format_module();
	exit_bl_mode();

	_time_delay(10);

	_i32         		retVal = 0;
	retVal = sl_Start(0, 0, 0);
	printf("\nsl_Start return code: %d", retVal);

	//ReadVersion();

	/* create/open the servicepack file for 128KB with rollback, secured and public write */
	printf("\nOpenning ServicePack file");
    _i32         		fileHandle = -1;

    _u32        		Token = 0;
    //_i32         		retVal = 0;
    _u32         		remainingLen, movingOffset, chunkLen;

	retVal = sl_FsOpen("/sys/servicepack.ucf",
			FS_MODE_OPEN_CREATE(LEN_128KB, _FS_FILE_OPEN_FLAG_SECURE|_FS_FILE_OPEN_FLAG_COMMIT|_FS_FILE_PUBLIC_WRITE),
			&Token, &fileHandle);
	if(retVal < 0)
	{
		sprintf(printBuffer, "\r\nCannot open ServicePack file. Error code: %d", (int)retVal);
		printf(printBuffer);
		return;
	}

	/* program the servicepack */
	printf("\nProgramming ServicePack file");

	remainingLen = sp_1_0_1_11_2_10_0_0_ucf_len;
	movingOffset = 0;
	chunkLen = (_u32)find_min(CHUNK_LEN, remainingLen);

	/* Flashing must be done in 1024 bytes chunks */
	do
	{
		retVal = sl_FsWrite(fileHandle, movingOffset, (_u8 *)&sp_1_0_1_11_2_10_0_0_ucf[movingOffset], chunkLen);
		if (retVal < 0)
		{
			sprintf(printBuffer, "\r\nCannot program ServicePack file. Error code: %d", (int)retVal);
			printf(printBuffer);
			return ;
		}

		remainingLen -= chunkLen;
		movingOffset += chunkLen;
		chunkLen = (_u32)find_min(CHUNK_LEN, remainingLen);
	}while (chunkLen > 0);

	/* close the servicepack file */
	printf("\nClosing ServicePack file");
	retVal = sl_FsClose(fileHandle, 0, (_u8 *)sp_1_0_1_11_2_10_0_0_ucf_signed_bin, sp_1_0_1_11_2_10_0_0_ucf_signed_bin_len);

	if (retVal < 0)
	{
		sprintf(printBuffer, "\r\nCannot close ServicePack file. Error code: %d", (int)retVal);
		printf(printBuffer);

		return;
	}

	printf("\nServicePack successfuly programmed\r\n\r\n");



	printf("Restarting CC3100... ");
	/* Stop the CC3100 device */
	sl_Stop(0xFF);

	/* Initializing the CC3100 device */
	sl_Start(0, 0, 0);

	ReadVersion();

}

Kind regards,

Stefan

Hi,

not sure why you send a format command from the code and not from Uniflash. Can you try it?

I am asking because if the format command is OK, I expect to get an ACK for it after a few seconds since this command takes time to erase a 1MB of flash but I do not see it.

The behavior you experience demonstrates a lack of file system which may be explained by failing to format the serial flash.

can you also show the implementation of bl_format_module() and enter/exit bl mode?

Shlomi

Hi,

I understand from the documentation that I need the CC31XXEMUBOOST kit for Uniflash which I don't have. Because of that, I use a host programming example for my case. My cc3100 module is integrated on the custom board. Can I use the Uniflash tool without the EMUBOOST kit?

Code snipets:

void enter_bl_mode()
{
		sl_DeviceDisable();
		sl_DeviceEnablePreamble();
		sl_IfOpen(NULL,NULL);
		cc3100_uart_set_break_signal();
		sl_DeviceEnable();

		wait_ack();
		cc3100_uart_stop_break_signal();

}

void bl_format_module()
{
	  printf("\r\nFormatting the device to 1MB");
	  sl_IfWrite(NULL, formatCommand[size1MB], sizeof(formatCommand[size1MB]));
	  wait_ack();

}

void exit_bl_mode()
{
	sl_IfWrite(NULL, disconnectCommand, sizeof(disconnectCommand));
}

Explanation for some functions:

- wait_ack() - this is the loop which ends when the MCU receive ACK(0xCC00)

- cc3100_uart_set_break_signal() - this function sets UART TX line to LOW.

- cc3100_uart_stop_break_signal() - restart UART TX pin function and TX line goes back to HIGH

Hi,

Thanks for the information. As long as you can connect from PC to the device via the same UART lines (via level shifter), you can use the Uniflash.

The reason I am asking for the Uniflash is that this is more reliable than the host programming and that you can do more operations from Uniflash like reading the file system.

in any case, if it is an issue, I can also suggest to fetch out logs from the internal network processor which shouldn't be hard. This way I can see whether the file system exists and also probe the procedure during actual format operation.

The procedure is described in one of my posts here https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/556699/sl_fsopen-fails-with--30-sl_fs_err_no_available_blocks/2039012#2039012

just ignore the muxing which applies only to CC3200 and all the rest is identical.

Shlomi

Hi Shlomi,

I try what you suggested. I format then flash cc3100 module. Also, I read the module file system after I formated it and after I flash the service pack image to the module. Logs that I get from the Uniflash tool:

• File system logs after device formated:

[23:51:57] INFO: --- please restart the device ---
[23:52:02] INFO: connection succeeded
[23:52:02] INFO: getting storage list
[23:52:02] INFO: > Executing Operation: Init
[23:52:02] INFO: reading version info
[23:52:02] INFO: DEVICE CC3100 ES1.33
[23:52:02] INFO: reading version info
[23:52:04] INFO: > Executing Operation: ListFileSystem
[23:52:04] INFO: extracting file system information...
[23:52:05] INFO: file start size fail total size filename
[23:52:05] INFO: index block [BLKs] safe [BLKs]
[23:52:05] INFO: ----------------------------------------------------------------------------
[23:52:05] INFO: N/A 0 5 N/A 5 FATFS
[23:52:05] INFO: 4 5 5 yes 10 /tmp/phy.cal
[23:52:05] INFO:

Flash usage
[23:52:05] INFO: -------------------------
[23:52:05] INFO: used space: 15 blocks
[23:52:05] INFO: free space: 241 blocks
[23:52:05] INFO: memory hole: [15-255]
[23:52:05] INFO: > Executing Operation: Disconnect
[23:52:05] Operation ListFileSystem returned

•  I format 512kb. Signal diagram for that process:

• Module flash logs and file system logs:

[00:17:55] INFO: > Executing Operation: ServicePackProgramming
[00:17:55] INFO: Path to the service pack file: /home/stefansdjordjevic/Documents/RFIDProj_docs/WiFi/CC3100_CC3200_ServicePack_1.0.1.11-2.10.0.0/servicepack_1.0.1.11-2.10.0.0.bin
[00:17:55] INFO: reading version info
[00:17:55] INFO: CC3100R Device detected.
[00:17:55] INFO: NWP/MAC/PHY Version from Service Pack:
[00:17:55] INFO:  NWP Patch version: 2.10.0.0
[00:17:55] INFO:  MAC Patch version: 1.5.0.2
[00:17:55] INFO:  PHY Patch version: 1.0.3.37
[00:17:55] INFO: reading version info
[00:17:55] INFO: DEVICE CC3100 ES1.33
[00:17:55] INFO: reading version info
[00:17:56] INFO: Downloading file "/sys/servicepack.ucf" with size 33700
[00:17:59] INFO:

New Token is 0x30E149EF
[00:17:59] INFO: Download complete
[00:17:59] INFO: > Executing Operation: Disconnect
[00:17:59] Operation ServicePackProgramming returned.
[00:18:33] Begin ListFileSystem operation.
[00:18:34] INFO: > Executing Operation: Connect
[00:18:36] WARNING: flush succeeded
[00:18:36] INFO: setting break signal
[00:18:36] INFO: --- please restart the device ---
[00:18:41] INFO: connection succeeded
[00:18:41] INFO: getting storage list
[00:18:41] INFO: > Executing Operation: Init
[00:18:41] INFO: reading version info
[00:18:41] INFO: DEVICE CC3100 ES1.33
[00:18:41] INFO: reading version info
[00:18:43] INFO: > Executing Operation: ListFileSystem
[00:18:43] INFO: extracting file system information...
[00:18:44] INFO:     file    start    size    fail    total size    filename
[00:18:44] INFO:     index    block    [BLKs]    safe    [BLKs]
[00:18:44] INFO: ----------------------------------------------------------------------------
[00:18:44] INFO:     N/A    0    5    N/A    5        FATFS
[00:18:44] INFO:     4    5    5    yes    10        /tmp/phy.cal
[00:18:44] INFO:     6    15    33    yes    66        /sys/servicepack.ucf
[00:18:44] INFO:

    Flash usage
[00:18:44] INFO: -------------------------
[00:18:44] INFO: used space:    81 blocks
[00:18:44] INFO: free space:    175 blocks
[00:18:44] INFO: memory hole:    [81-255]
[00:18:44] INFO: > Executing Operation: Disconnect
[00:18:44] Operation ListFileSystem returned.

Can we conclude from these logs that the device is now flashed with the new firmware?

However, I still have the same problem. I still get ROLE_UNKONW error from sl_Start call and API_ABORTED from sl_Get call. The signal diagram for these two API calls is the same when the module is formated and when the module is flashed:

Shlomi Itzhak said:

I can also suggest to fetch out logs from the internal network processor which shouldn't be hard. This way I can see whether the file system exists and also probe the procedure during actual format operation.

The procedure is described in one of my posts here https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/556699/sl_fsopen-fails-with--30-sl_fs_err_no_available_blocks/2039012#2039012

I looked at the pin map of cc3200QFN and at the pin map of cc3100MOD. I found that pin that you mentioned (pin #62) that is used for network logging is UART TX pin on the cc3200QFN module. From what I saw from the pin map for cc3100MOD there is no same pin for network logging, there is no another TX pin on the cc3100MOD module.

Thank you for your help,

Stefan

Hi,

At least from Uniflash perspective I can see that the file system is created.

Why do you use 512Mb and not 1MB (the module should have 1MB)?

I do not see in the last logic capture these two APIs. I expect that for the sl_Start() there would be nHib toggling for example.

Is it possible to get the raw capture for the logic instead of screen capture?

As for the NWP logger, the pin for the CC3100MOD should be #52. 

Regards,

Shlomi

Hi,

Shlomi Itzhak said:

Why do you use 512Mb and not 1MB (the module should have 1MB)?

- I format to 512kb because I wasn't sure that the module had 1MB memory so I chose the smaller size. I understand that I can flash the module even if I formated it on a smaller size.

Shlomi Itzhak said:

As for the NWP logger, the pin for the CC3100MOD should be #52. 

- Because of my PCB design it is really difficult for me to access the pin you mention. I will try to reach that pin if it is necessary.

Shlomi Itzhak said:

Is it possible to get the raw capture for the logic instead of screen capture?

- My nHib and IRQ pin wasn't connected correctly to the logic analyzer. Sorry for the bad capture. This is raw capture of a logic analyzer:

rec01.zip

Thank you for your help,

Stefan

I did 1Mb format then I flash the image to the module. After that I try my code and I got the same results from the logic analyzer.

Uniflash logs: Uniflash_logs.zip

Logic analyzer capture for format, flash and list file system uniflash operations: Logic.zip

Regards,

Stefan

How can I open these logic files?

You can open it using Salea app. I will attach here csv files for every capture: Logic_CSV.zip

You can open it using Salea app. I will attach here csv files for every capture: 3808.Logic_CSV.zip

Thanks,

it is really hard to debug this way.

would be good if you can make the NWP log to work.

what uniflash version are you using? you can see it under help->about

also, can you open the extra debug in Uniflash? you can under windows->preferences. Then choose Uniflash Preferences and mark the "Print out additional debug..."

I will keep on looking at the logic logs.

Shlomi

another option before the NWP phase, you can also capture the lines when you call sl_Start() which fails.

maybe i can see something wrong coming from the device.

I am using uniflash v3.4.0. I have a problem installing v3.4.1 so I install this version. I am using Linux PopOS.

Stefan Djordjevic said:

- My nHib and IRQ pin wasn't connected correctly to the logic analyzer. Sorry for the bad capture. This is raw capture of a logic analyzer:

rec01.zip

- This is the capture of the communication between the MCU and the wifi module when sl_Start() and sl_Get() are called. Should the wifi module send something when it is restarted or should MCU send something to the wifi module first?

This is the uniflash logs with additional debug logs: uniflash_debug.zip

Regards,

Stefan

Hi,

Uniflash logs looks OK.

For UART, slStart() turns on the chipset which then initializes. When it is done, the device should send the init_complete event. Unlike SPI, the host does not need to pull the message but the message should be driven from the device and then the sl_Start() should be released.

In your case, I can see that both RTS and CTS (not sure which is coming from the host and which from the device) are high which implies a flow control saying "not ready to receive data) and this is probably why the device does not send the data.

Can you please check it?

Shlomi