CC3200 AWS IoT Subscribe Publish Sample VERIFY_PROTOCOL problem.

Hey,

Here is the screenshot for the C call stack, I'm trying something else with it now, will give you the ROV view ASAP.

Okay, here is what I have been able to do:-

1. It used to randomly end up on the above given error for the certflasher.out file load run. But after power cycling, certflasher.out has worked perfectly both the times that I've tried until now.

2. After the certificates get flashed. I press Alt+F8 to suspend the certflasher.out program. Then, without resetting the device, I load up the subscribe_publish_sample.out file. Before running it, I make the serial connection with the Tera Term software so that I can recieve the replies.

3. After that, I run the loaded up sample and wait for a minute for any response to come up in Tera Term. Nothing comes up.

4. So, I suspend the program by pressing Alt+F8 and end up with the following screenshot (if you need any other view in the ROV, let me know):-

5. If I continue to locate the file, then it leads me to the VERIFY_PROTOCOL endless loop. 

How do I solve this from here? Let me know if you need any other information. BTW, I'm using the latest version of all the required tools and SDKs.

Can you try setting some break points in your app and then re-running?

1. in main.c, set a break point at the beginning of the definition of the simple link task "void slTask(unsigned int arg0, unsigned int arg1)"

2. in netwifi.c, set a break point at the beginning of NetWiFi_init()

3. in startsntp.c, set a break point at the beginning of startNTP()

4. in the subscribe_publish_sample.c (the one in subscribe_publish_sample/platform_tirtos/cc3200/), set a break point at the beginning of runAWSClient().

Do you hit these break points?

Steve

Meanwhile, I will be trying to run the SDK as a CCS Library and then importing the library into my own CCS Project as mentioned in this forum: e2e.ti.com/.../1860104. Will let you know if this works out.

Pratyush,

Thanks for posting that video.  I noticed that you first load the application, and then proceed to single step through a large portion of the program.  Have you been single stepping like that in your previous attempts to get the application to work?

If so, I think you should retry.  First, in CCS disconnect the 3200 and then unplug/replug its USB cable.  Then reconnect/reload your app in CCS.

This time, do not single step.  Just run the application from the start.  Do you still see this issue?

The reason single stepping is not a good idea is because the 3200 has 2 processors running on it.  You are connected to the M4 core in CCS, and so CCS can control that core to halt/run it when you single step.  But, the 3200's TCP/IP stack is actually running independently on another core - an M3 that's also on the 3200.

The network data travels between the M4 and the M3 over the SPI bus.  The problem is that when you halt the M4 in CCS, you are not halting the M3 core, so the network stack is still running and trying to do SPI operations.  The two cores can quickly get out of sync and you'll hit issues like this.

If you still see the issue, I'm wondering if it could be related to another issue we've seen with the SPI transfers switching from DMA transfers to polling transfers.  See this thread.

I would also recommend that you power cycle the 3200 in between each load/run of your application.  This may seem extreme, but it may save you a lot of headache. The reason is for the same as above - the M3 core will sometimes continue to run and you'll hit problems when your app loads on the M4 and tries to start up network comm with the M3.

Another note on your video, I see in your single stepping that you seem to be pointing out the call to Error_init() within the HwiP_create() function. This shouldn't be a problem, it is just initializing the error block (it's not actually hitting an error).

Finally, if you still hit the issue after a fresh power cycle/reloading/rerun without single stepping, please zip up and attach your entire *built* sub/pub example (with your modifications) to this thread so I can review.

Steve

Humanesq,

Have you reset your 3200 board?  If you halted the main processor on the 3200 (the M4) in the middle of a SPI transaction, then the M3 (where the SimpleLink stack runs) will get hung up.  (see above explanation of this, also)

You need to disconnect your 3200 from CCS, unplug the USB cable, re-plug the USB cable, then reconnect in CCS and try again.

Steve

Hi, 

i am also encountering the same problem.Has anyone got an solution to it?

Hi Sumit,

Have you power cycled your board?

I recommend that you do that before each program load/run.  As mentioned above, the network processor is probably hung up.

Steve

hi steven,

I fixed this problem by flashing the certificates into the cc3200 first through uniflash and then loading the .out file of the example. Maybe there was some problem while loading both the .out files one after another.

regards,

sumit

Hey Humanesq,

Make sure the certificates and keys that you are saving are correct and are converted to .der format using openssl or any other tool.

Hi Humanesq,

Just make sure to convert the .pem certificate and key files into .der format. To do so either use openssl or use (http://www.entrust.net/knowledge-base/technote.cfm?tn=5531) to convert certificates and for keys use (https://www.trustico.co.in/ssltools/convert/pem-key-to-der/convert-pem-private-key-to-der.php) and flash it then using the procedure given in the video.

Sumit

(1) Converted the .pem certificate and key files into .der format and flashed them using Uniflash.

Below are the files i see on device
[20:04:05] INFO: 4 5 5 yes 10 /tmp/phy.cal
[20:04:05] INFO: 6 15 33 yes 66 /sys/servicepack.ucf
[20:04:05] INFO: 7 81 1 no 1 /cert/ca.der
[20:04:05] INFO: 8 82 1 no 1 /cert/cert.der
[20:04:05] INFO: 9 83 1 no 1 /cert/key.der

(2) Unplugged/Replugged Board, Opened CCS, Connected to Target and Downloaded "subscribe_publish_sample.out" application. Application worked!!

BUT ONLY ONCE!

If i Terminate session, Repower Board, Launch new session, Connect Target, Hit Core Reset couple time (as indicated in forum before), and Load the application program, i get stuck again in VERIFY_PROTOCOL().

I have to redo the "Whole process" again (i.e. step (1) and (2)) to make it work one more time.

So something is going on which prevents application from running the second time (without re-doing Step (1))

Below are the list of files i see after the application is run once
[20:04:05] INFO: 4 5 5 yes 10 /tmp/phy.cal
[20:04:05] INFO: 6 15 33 yes 66 /sys/servicepack.ucf
[20:04:05] INFO: 7 81 1 no 1 /cert/ca.der
[20:04:05] INFO: 8 82 1 no 1 /cert/cert.der
[20:04:05] INFO: 9 83 1 no 1 /cert/key.der
[20:04:05] INFO: 10 84 1 yes 2 /sys/stacfg.ini
[20:04:05] INFO: 11 86 1 yes 2 /sys/ipcfg.ini
[20:04:05] INFO: 12 88 1 yes 2 /tmp/table.arp

Any feedback?

Also, below is another thread which has been running for some time now. Has much more technical details, but no answer on the forum. 

https://e2e.ti.com/support/wireless_connectivity/simplelink_wifi_cc31xx_cc32xx/f/968/p/384722/1376926#pi239031350=5

What jumper configuration do you have set for the SOP pins?

Can you try setting SOP to "100", i.e. put a jumper onto J15 only on the SOP? (and J16, J17 would have no jumper)

Do you get better results if you do that?

Steve

Yes. Jumper is on J15 only, as is mentioned @ 3:29 in Project 0 video. 

###### User Step: Update install paths to XDCtools, TI-RTOS, and Compiler ######
XDC_INSTALL_DIR       = C:/TI/xdctools_3_32_00_06_core
TIRTOS_INSTALL_DIR    = C:/TI/tirtos_cc32xx_2_16_01_14
TI_ARM_CODEGEN_INSTALL_DIR = C:/TI/ccsv6/tools/compiler/ti-cgt-arm_5.2.7

###### Below dependencies are determined automatically ######
TIDRIVERS_INSTALL_DIR := $(wildcard $(TIRTOS_INSTALL_DIR)/products/tidrivers_*)
BIOS_INSTALL_DIR    := $(wildcard $(TIRTOS_INSTALL_DIR)/products/bios_*)
UIA_INSTALL_DIR     := $(wildcard $(TIRTOS_INSTALL_DIR)/products/uia_*)
NS_INSTALL_DIR      := $(wildcard $(TIRTOS_INSTALL_DIR)/products/ns_*)

CCWARE_INSTALL_DIR := $(wildcard $(TIRTOS_INSTALL_DIR)/products/CC3200_driverlib*)
CC3200SDK_INSTALL_DIR := $(TIDRIVERS_INSTALL_DIR)/packages/ti/mw/wifi/cc3x00

Humanesq,

I wanted to update you on the potential solution that I mentioned during the phone call last week.  I'm talking about building SimpleLink for development mode vs. deployment mode (as mentioned in section "15.1 Simplelink build - Deployment Scenarios Vs. Development mode" of the CC3200 SDK release notes. I believe you installed the SDK as well so you can check out that section for details.).

Unfortunately, I found that the version of SimpleLink that's in TIRTOS is already built for development mode, and the network preamble function is already being called to reset the NWP.

However, we have another idea here.

We are suspecting that something flashed previously to your CC3200 (some other app) is starting up the network processor before your sub/pub application has a chance to load/run from CCS.

Can you try flashing the app in the attached CCS project?  This app called "hold" is meant to hold the NWP from starting.  It will spin in main() and blink an LED, never calling SimpleLink start and so the NWP should never start with this app.

The idea is that when you power on your 3200, the "hold" app (that's flashed) will run first, but it won't start the NWP.

Then, you load your sub/pub example and run, and it will be the first app to actually start the NWP and the SPI communication between the M4 and the NWP should all be in sync.

Steve

6138.hold_CC3200.zip

Hi Steve,

So here are my try details based on your recommendations

1. Created a .bin file so i could flash it on device

2. Flashed hold_CC3200.bin and AWS Certs. Here is the snapshot of my Configuration

Below is the list of files AFTER flashing

[11:07:34] INFO: 	N/A	0	5	N/A	5		FATFS
[11:07:34] INFO: 	0	81	11	no	11		/sys/mcuimg.bin
[11:07:34] INFO: 	4	5	5	yes	10		/tmp/phy.cal
[11:07:34] INFO: 	6	15	33	yes		  /sys/servicepack.ucf
[11:07:34] INFO: 	7	92	1	no	1		/cert/ca.der
[11:07:34] INFO: 	8	93	1	no	1		/cert/cert.der
[11:07:34] INFO: 	9	94	1	no	1		/cert/key.der

3. Next,  Removed the SOP Jumper (on J15 pin) and hit RESET. The Red LED started Flashing just as you described in your post. 

4. Opened CCS and Launched Debug session and Loaded and Ran subscribe_publish_sample.out. The problem was not resolved !!

Details - 

On first try the program did not run as expected (which without loading the hold_CC3200.bin, it usually works as mentioned in previous posts). On Repowering and running  subscribe_publish_sample.out for 2nd time, it does gets stuck in VERIFY_PROTOCOL call. So it is showing same symptoms as before. Also, i was not sure while running CCS, it the SOP Jumper should be put back on? So i tried it both ways (On and Off) with similar results. 

Please let me know if there is anything else i can try or if i am following instructions incorrectly. 

Thanks. 

Steve,  FYI I found the same thing with my board after programming it with a .bin file that just blinks an LED.  Also, note that if I program the board with a .bin of the AWS demo, it does not seem to execute even after power cycling/resetting.

Ditto. Creating a .bin file of AWS Demo and flashing it does nothing for me too. Have to use via CCS to make AWS Demo work. 

Interesting.  Your procedure does not work for my second Launchpad; it still gets stuck at VERIFY_PROTOCOL even after using Uniflash to format, program service pack & cert files, then using CCS to program either the .out or enter into debug with my project.  Note that if I build a .bin of the AWS code and use Uniflash to program it as mcuimg.bin, it will run successfully.

My working Launchpad seems to bullet proof (knock on wood).  I can run from debug mode and it works every time, power cycle or not.  I can stop and re-run AWS demo without any issue (power cycle or not).  Note I have not tried formatting this board as I'm pretty sure that would take it back to not working.

To clarify, it works when programming the .bin only if I remove/reapply USB cable.  If I try to use the reset button, it seems to be stalled.  Power must be removed.

For your situation, when you power cycle (removing USB cable), are you disconnecting/reconnecting your terminal program?  I know TeraTerm requires disconnect/reconnect if a connected USB device gets removed  (otherwise nothing will come through even though it looks connected).

Hi Jon,

Are you trying to read files stored in the flash?  SimpleLink has an API to do this.  If this isn't what you mean, I would suggest that you make a new post on the SimpleLink forum to ask about this.  The team there would know the answer.

Jon Schweiger said:

I've got 1 working and 1 non-working Launchpad, but I need your help.

Are your boards identical?  I.e. same revision number and processor number?

Steve

Hi Steve

Yes, both boards are identical and worked well with the demo/example wlan_station project. The board details are (in case it is useful:

CC3200-LAUNCHXL, Rev 4.1

MCU 1: cc3200R1 M2, 4B3 ZHCD G3

MCU 2: cc3200R1 M2, 513 ZDRN G4

Was using the v1.1.1-ti, not sure is this a issue. Will be trying with the project on the master and update.

Thanks, JL

Hi Pratyush Raj,

I´ve been facing the same problems with cc3200 and simply cant make it work on aws. I have tried evreything that was suggested, but didn´t get resuts. You mentioned that you could use energia and communicate with AWS. Do you have any example of this, or maybe some tutorial? 

Thank you

I have the same problem - locking up in VERIFY_PROTOCOL on the first call to simplelink, sl_Start() in setStationMode.

Using the following versions:

TI-RTOS 2.16.1.14
XDCtools 3.32.1.22_core
Service pack 1.0.1.6-2.7.0.0

SOP2 jumper is on and I power cycle the board before each launch with the debugger so there should not be any other application loaded to the M4 which means the M4 and NWP should not be out of sync (right?).

Seems like a timing problem to me.  Here is my workaround:

Add Task_sleep(50) after the first call to sl_Start(0, 0, 0) in setStationMode().   Don't know why but this seems to fix the problem for me on multiple computers and multiple Launchpads.

Randomly chose 50 ms... haven't tested to see what range works.  If I remove the Task_sleep(50), the program will run for a few more times but then once it stops running, it locks up again every time on sl_Start until you add the Task_sleep, power cycle the launchpad, and run again.

As long as Task_sleep() is called after sl_Start() and you power cycle the board once, it works every time after without needing to power cycle the board again.

Like this:

void setStationMode(void)
{
    int           mode;
    int           response;
    unsigned char param;

    mode = sl_Start(0, 0, 0);
    if (mode < 0) {
        System_abort("Could not initialize SimpleLink Wi-Fi");
    }

    Task_sleep(50);  // This was the work-around (for me)

    /* Change network processor to station mode */
    if (mode != ROLE_STA) {
        sl_WlanSetMode(ROLE_STA);

        /* Restart network processor */
        sl_Stop(0);
        mode = sl_Start(0, 0, 0);
        if (mode < 0) {
            System_abort("Failed to set SimpleLink Wi-Fi to Station mode");
        }
    }

Any thoughts about what's going on?

All,

I've been informed of a potential solution to the VERIFY_PROTOCOL issue.  However, since I'm unable to reproduce the issue, I cannot confirm that the potential fix actually works.  But I wanted to list it here in case anyone in the community would like to try it.

The update needs to be made to the following file in your TI-RTOS installation:

tirtos_cc32xx_2_16_00_08\products\tidrivers_cc32xx_2_16_00_08\packages\ti\drivers\wifi\WiFiCC3200.c

----------------------------------------------------------------------------------------------------------------------

1. modify the function CC3X00_NWP_enable() with the following change (highlighted):

void CC3X00_NWP_enable(void)
{
#ifdef CC3200_ES_1_2_1
    /* SPI CLK GATING */
    HWREG(0x440250C8) = 0;

    /* WLAN PD ON */
    HWREG(0x4402E168) &= ~(0xC00);

    /* Remove NWP Reset */
    HWREG(0x4402D000) &= ~4;
#else
    /* Bring the 1.32 eco out of reset */
    HWREG(0x4402E16C) &= 0xFFFFFFFD;
#endif

    /* Clear host IRQ indication (potential fix for VERIFY_PROTOCOL) */
    HWREG(0x400F7094) = 1;

    /* NWP Wakeup */
    HWREG(0x44025118) = 1;

#ifndef DISABLE_DEBUGGER_RECONNECT
    UtilsDelay(8000000);
#endif

    /* UnMask Host Interrupt */
    CC3X00_NWP_unMaskInterrupt();
}

2. Rebuild the TI-RTOS drivers. Please refer to the TIRTOS documentation for the steps on how to rebuild TIRTOS

3. Rebuild, power cycle your 3200, reload the app and run

Steve