PSOC5 LP with ESP8266-01 update data to ThingSpeak channel issue

[Y_r]

Hello @MotooTanaka san and @Len_CONSULTRON ,

While trying to update data to a ThingSpeak channel using PSOC5 LP and ESP, I have tried using the "CIPSTART" command to connect to the particular IP address of ThingSpeak and the response from the server was also "CONNECT OK" which means that the link is established, but there is a sprint() statement after, which is responsible for updating the value to the certain channel and field using the APIKey, but the control never reaches this sprintf() statement in the ESP_Send_Data() function in the firmware (I have tested this using CySoftwareReset() API at two positions in the ESP_Send_Data() function, one at line 143 (which resets the firmware and executes from start) and at 146 (which never works)).

I have attached the firmware bundle and the Error log (ESP_CIPSTART_ERROR_LOG.docx) in the thread.

Please advise on why is the control stuck after the CIPSTART line, even though there is a "CONNECT OK" response from the server?

Any help would be appreciated.

Regards,
Yash

[Len_CONSULTRON · Accepted solution]

Yash,

Downloaded your code.  It's obvious why it hangs at line 144 in ESPDataLogger.c

Line 144  waits for a non-zero return from WaitText().  If a zero is returned, you loop in the while().

	while (!(WaitText("OK\r\n",1000)));

However in WaitText() you ALWAYS return with a ZERO!!!!  (See line 74).

uint16  WaitText(char *target, int time) 		 
 {
...
return 0;	
} 

 Therefore you are stuck in an infinite loop.

Suggestion:

You have a lot of while()s and do{}while()s in your code.  Be careful.  Using these without careful understanding can lead to an infinite loop.   

The issue is further compounded by the fact that you are using this do/while statements when communicating with another device.   You may not always get what you are expecting especially since you don't have full control over this other device.   For example, what if a communication error occurs?

I see that you have put a timeout in the WaitText() API call.  This is good for while() statements.   May I suggest that the return from the function be 0 = Text Match!!!  1= No text match  2 = Timeout occurred   3= any more errors you need to define.   

Get rid of the while() at line 144.  It's dangerous.   Once a return occurs, if "Match" then proceed to the next step in the code.  If "No Match", issue the command again?   If a "Timeout", make sure the comm is working.

In general, find a way to eliminate the while()s and do{}while()s if you can.

[Y_r]

Hi Len,

Can't thank you enough for pointing out the flaw in the while() loop implementation. 
Turns out, that was exactly the issue. I was not expecting that there could be an issue there since the same piece of code was working properly on an STM board (found that the implementation of the WaitFor in STM is different).
After changing the while loops to respective if-else conditions, the program now works as expected.

"I see that you have put a timeout in the WaitText() API call.  This is good for while() statements.   May I suggest that the return from the function be 0 = Text Match!!!  1= No text match  2 = Timeout occurred   3= any more errors you need to define.   "
>> I will be implementing your suggestions into the firmware 😊.

Thanks and Regards,
Yash

[Len_CONSULTRON]

Yash,

We're welcome.

The problem I have seen with communicating with devices that have their own events and their own 'intelligence'  is that the 'expected' responses are not always guaranteed.   

I remember the 'AT' commands you are using are borrowed from old modem technology.   It was a simple asynchronous protocol that had some degree of flow control  It was primarily intended to instruct the modem how and when to dial-out (by telephone) to the remote end.   Once the remote end is connected, the data is effectively transparent.

Some of the problem I remember using the AT command set is when events occur due to the remote end or the telephone connection, it was hard to interpret the proper correction due to the unexpected communication from the modem.

Another suggestion:   I have also found that with intelligent devices that DO NOT have a HW reset signal, that I need to power that device through a switchable power source.  If the comm from the PSoC to the device has no response (the device is in an unknown state due to lockup?) the PSoC can switch the device power OFF.   This is the only other choice to reset the device without a HW reset signal.