Differences when programming the CC3200 module (cc3200mod)

Hi Severine,

The module comes preloaded with the latest Service Pack (for the time when the module was programmed) and the Out Of Box example.

Should be straight forward and compatible with the LaunchPad (that is probably occupied with The QFN flavor of CC3200).

Can you elaborate the setup? How did you connect the module?

Shlomi 

Hi,

It would be interesting to realize why it ends up in fault ISR as I cannot think of a reason.

Shlomi

Severin,

I'm working on Windows with CCS IDE.

Any of the examples in the SDK would work (most of them have sl_start). You can pick any.

You are using gdbon Linux, right? it seems as it fails on the first line lRetVal = -1;. Where do you see it fails on sl_start()?

Can you describe your setup with the module (hardware wise)?

Shlomi

Hello Shlomi,

yes I use gdb and openocd on Linux. Although gdb says it fails on lRetVal = -1;, the code definitely executes further than that. When I instrument the code with printf (Report) calls, I will see it fail on line 435 of main.c (in the tcp_socket example). This is lMode = sl_Start(0, 0, 0);. A Report("test\n\r") before the sl_Start call will be output on the console, while a Report right after it will never be printed. If i step through the code with gdb it will fail when calling NwpPowerOn (see gdb session at the end of this post).

We now also experimented with another CC3200 module and see a slightly different behavior: It will execute until the sl_Start, but then fail at the ASSERT right after it. It will fail with "Error [-1] at line [437] in function [ConfigureSimpleLinkToDefaultState]", which suggests _sl_GetStartResponseConvert (called in sl_Start) returns ROLE_STA_ERR.
I am not sure if these two problems could have the same root cause and I am not sure why two identical chips react differently. A CC3200 Launchpad will execute the same code in the same environment (same host computer and access point) correctly.

Do you have any ideas on how to narrow the problem down?

Cheers,
Severin


Here is the gdb session:
Breakpoint 1, main () at ../main.c:1123
1123 long lRetVal = -1;
(gdb) break sl_Start
Breakpoint 2 at 0x20005a20: file ../source/device.c, line 97.
(gdb) c
Continuing.

Breakpoint 2, sl_Start (pIfHdl=0x0, pDevName=0x0, pInitCallBack=0x0)
at ../source/device.c:97
97 _i16 ObjIdx = MAX_CONCURRENT_ACTIONS;
(gdb) next
101 sl_DeviceEnablePreamble();
(gdb) next
104 _SlDrvDriverCBInit();
(gdb)
107 if (NULL == pIfHdl)
(gdb)
109 g_pCB->FD = sl_IfOpen((void *)pDevName, 0);
(gdb)
116 ObjIdx = _SlDrvWaitForPoolObj(START_STOP_ID,SL_MAX_SOCKETS);
(gdb)
117 if (MAX_CONCURRENT_ACTIONS == ObjIdx)
(gdb)
121 OSI_RET_OK_CHECK(sl_LockObjLock(&g_pCB->ProtectionLockObj, SL_OS_WAIT_FOREVER));
(gdb)
122 g_pCB->ObjPool[ObjIdx].pRespArgs = (_u8 *)&AsyncRsp;
(gdb)
123 OSI_RET_OK_CHECK(sl_LockObjUnlock(&g_pCB->ProtectionLockObj));
(gdb)
125 if( g_pCB->FD >= 0)
(gdb)
127 sl_DeviceDisable();
(gdb)
129 sl_IfRegIntHdlr((SL_P_EVENT_HANDLER)_SlDrvRxIrqHandler, NULL);
(gdb)
131 if(NULL != pInitCallBack)
(gdb)
135 sl_DeviceEnable();
(gdb) s
NwpPowerOn () at ../cc_pal.c:799
799 HWREG(0x4402E16C) &= 0xFFFFFFFD;
(gdb) s
803 HWREG(0x44025118) = 1;
(gdb) s
805 UtilsDelay(8000000);
(gdb) s
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x20005566
Cannot insert breakpoint 2.
Cannot access memory at address 0x20005a20

Hi Severine,

The only thing I can think of is if you have a pull down on the RX UART line used for flashing (I believe it is pin #47. Can you please check it?

Also, since it is custom board, how did you connect the UART lines (pin #46 and #47)? Are you able to work with Uniflash and program the module?

Shlomi

Hi Shlomi,

Interesting point. In fact, ping 47 (UART RX) is broken out on our board and it is connected to an (external) FTDI UART to USB converter.

What is unclear to us is what you mean by flashing. From the reference schematic (section 6.1 in the CC3200MOD datasheet) I can see that pins 35 (nReset), 46 (GPIO 1), 47 (GPIO 2) and 23 (SOP2) are connected to a "FLASH PROGRAM" header.

We are not making used of this "FLASH PROGRAM" interface but use the JTAG interface (TCK, TMS, TDI and TDO) for programming.
As I wrote previously pins 46 and 47 are connected to an FTDI chip. Is this something we should not do? What is expected to be flashed via this flash interface and how is this related to our radio startup problem?

Thanks,

Thomas & Severin

Hi,

It is mostly for CC3100, not CC3200. Sensing low level on RX would make CC3100 device go into boot loader mode during initialization. Since you use CC3200 it is not the case. In any case, it is just another way to test if you are able to flash your custom board via the UART lines using Uniflash (you would need to do it at some point with the new service packs that come out).

Additionally, reading the entire post I can see: "And we have broken out the SPI pins because we plan to interface our CC3200 with an other internally designed MCU-board later on." Can you explain what exactly you did with the SPI lines? which pins did you route and to where?

I'm asking because not passing sl_start() implies either:

1. not powering the device + not toggling nHib/nReset
2. Host IRQ line is not connected
3. SPI lines are broken

Another test is to set a breakpoint at the IRQ handler and see if you get there. After the device is initialized, it assert the IRQ to the host. you should trap it.

Shlomi

Hi,

It does not shed more light.

Can you please follow my request and let me know if you get to _SlDrvRxIrqHandler().

Also, what did you mean by breaking the SPI pins?

Shlomi

Hi Severine,

Really hard to follow the DGB debugger.

Let me try to explain the expected from in details (with potential issues) so you can try to follow in your implementation:

1. invoking sl_start() power on the device.
2. at device initialization process ends, the device asserts an interrupt to the host for signaling. Any issues with the IRQ line would make the host keep waiting forever. In your case, you get to the breakpoint so most chances are that this is OK (unless you have jitter on the IRQ line causing some kind of a false alarm).
3. Until an IRQ is received, the host is blocked on _SlNonOsSemGet() invoked from within sl_start(). In _SlNonOsSemGet(), it continuously calls _SlNonOsMainLoopTask() to check if the spawn function has been registered by the interrupt handler
4. upon interrupt reception, the _SlDrvRxIrqHandler() is invoked, registering the spawn handler _SlDrvMsgReadSpawnCtx() and exists
5. _SlNonOsMainLoopTask() is finally invoked, calling to the registered function via pF(0);/*(pValue);*/ line
6. _SlDrvMsgReadSpawnCtx() calls _SlDrvMsgRead() and then _SlDrvRxHdrRead() which write CNYS pattern on the SPI lines and read back SYNC pattern and then continues. Failing to write CNYS or read SYNC as a result of SPI lines issues would make the system get stuck

Hope the procedure is clear so you can follow and check the SPI, IRQ lines. This is the reason I asked on breaking the SPI lines as it may be related to the issue you are observing.

Shlomi

Shlomi

Hi Severine,

It has been a while. Any update on the issue? have you figured out the root cause? if not, please let me know where it fails according to my latest post.

Shlomi

No,

It fails during debugging, nor programming. besides, they succeed in downloading the code and debugging.

Shlomi