CC3220: AWS shadow_sample example

Hi David,

When you say that the transmission hangs, which call causes it to hang? Have you tried running the example in debug mode and seeing what exactly causes the crash to happen? Also, have you checked the state of the RTOS using the RTOS object viewer (accessible from tools->ROV classic)? Using the ROV you can check to ensure you have enough heap, and that you are not overflowing a stack somewhere.

Other than that, you might also want to try changing the TX buffer length so that it matches that of the RX buffer.

Let me know if those steps don't help you resolve this issue.

Regards,
Michael

Hi Michael,

Sure, sorry for not including in the previous post, it gets lost in the following call inside _aws_iot_mqtt_internal_connect function:

rc = pClient->networkStack.connect(&(pClient->networkStack), NULL);

I am not sure how to address this.

In my test I increased both RX and TX to 1024. 

If this is heap/stack overflow issue, I am not sure how to work with RTOS object viewer. In which menu is it located in CCS?

Thanks,

David

Also, I didn't touch MAX_LENGTH_OF_UPDATE_JSON_BUFFER.
Does it need to be modified if RX and TX buffer size is modified?

Thanks,
David

Hi Michael,

If this is stack/heap related, which module should I check in ROV? Could share a quick advice on how to detect a potential problem by looking at the ROV menus for a given module?

Thanks,
David

Michael,

To facilitate debug, I to the original shadow_sample example and ONLY changed TX and RX buffer size from 512 to 1024:
// MQTT PubSub
#define AWS_IOT_MQTT_TX_BUF_LEN 1024 // modified by david, was 512 ///< Any time a message is sent out through the MQTT layer. The message is copied into this buffer anytime a publish is done. This will also be used in the case of Thing Shadow
#define AWS_IOT_MQTT_RX_BUF_LEN 1024 // modified by david, was 512 ///< Any message that comes into the device should be less than this buffer size. If a received message is bigger than this buffer size the message will be dropped.

That's the only change. And the example failed. You can confirm on your end as well. I think a general guidance for such case would be very helpful for many users.

Thanks,
David

Hi David,

Changing the length of MAX_LENGTH_OF_UPDATE_JSON_BUFFER is also needed if your AWS shadow JSON is particularly large. Another define that I changed was MAX_SIZE_OF_THING_NAME, since my thing name was particularly long.

Still, the shadow_sample example should work correctly without having to change the buffer settings. When you reverted back to the unmodified shadow_sample example, do you get the same error or something different?

To use the ROV tools, first launch your program with the debugger. Then, once the debugger has finished loading your code, in the upper menu bar select "tools", then click on ROV classic. From there, you should have a window in the lower right appear with some RTOS details. After that, select the "heapMem" or "task" list entry, and select the "detailed" tab. You should find a wealth of debug information such as the amount of heap remaining, the current/max stack sizes of each task, etc.

Regards,

Michael

Michael,

The original shadow_sample example works correctly. For my debug purpose, in order to see the impact of TX/RX buffer size, I tried to change TX and RX buffer size from 512 to 1024 in the original example as follows:

// MQTT PubSub

#define AWS_IOT_MQTT_TX_BUF_LEN 1024 // modified by david, was 512 ///< Any time a message is sent out through the MQTT layer. The message is copied into this buffer anytime a publish is done. This will also be used in the case of Thing Shadow

#define AWS_IOT_MQTT_RX_BUF_LEN 1024 // modified by david, was 512 ///< Any message that comes into the device should be less than this buffer size. If a received message is bigger than this buffer size the message will be dropped.

That's the ONLY change I did in the original shadow_sample example. And the example failed. 

Now my next step is to understand WHY it is failing and I am following the ROV. Below is the screenshot of heapMem:

I am not sure but from what it shows it seems like there is no problem. Can you confirm?

Thanks,

David

Hi Michael,

My current test is running on original example with TX/RX changed to 1024. No additonal structs. For this, the program is stuck in the while loop in Hwi_excHandler (Hwi.c):

/*
 *  ======== Hwi_excHandler ========
 */
Void Hwi_excHandler(UInt *excStack, UInt lr)
{
    Hwi_module->excActive[0] = TRUE;

    /* spin here if no exception handler is plugged */
    while (Hwi_excHandlerFunc == NULL) {
	;
    }

    Hwi_excHandlerFunc(excStack, lr);
}

The heapmem and task screenshots are below:

I can see task shows red. I increased it to 8192 in main and it work. You helped very much. The same remedy worked for my main application as well. 

Thanks,

David