Topics created by cocoa

@felmue It works in a totally random way, sometimes it gets the answer to the 'GET' and then it enters an infinite loop:

AT+CIPRXGET=4,0 07:25:49.725 > 07:25:49.727 > +CIPRXGET: 4,0,0 07:25:49.727 > 07:25:49.727 > OK 07:25:49.727 > AT+CIPCLOSE? 07:25:49.734 > 07:25:49.735 > +CIPCLOSE: 0,0 07:25:49.735 > 07:25:49.735 > OK 07:25:50.219 > AT+CIPRXGET=4,0 07:25:50.226 > 07:25:50.226 > +CIPRXGET: 4,0,0 07:25:50.227 > 07:25:50.227 > OK 07:25:50.228 > AT+CIPCLOSE? 07:25:50.234 > 07:25:50.234 > +CIPCLOSE: 0,0 07:25:50.236 > 07:25:50.236 > OK 07:25:50.720 > AT+CIPRXGET=4,0 07:25:50.727 > 07:25:50.728 > +CIPRXGET: 4,0,0 07:25:50.728 > 07:25:50.728 > OK 07:25:50.728 > AT+CIPCLOSE? 07:25:50.736 > 07:25:50.736 > +CIPCLOSE: 0,0 07:25:50.736 > 07:25:50.737 > OK 07:25:51.221 > AT+CIPRXGET=4,0 07:25:51.229 > 07:25:51.230 > +CIPRXGET: 4,0,0 07:25:51.230 > 07:25:51.230 > OK 07:25:51.230 > AT+CIPCLOSE? 07:25:51.237 > 07:25:51.237 > +CIPCLOSE: 0,0 07:25:51.238 > 07:25:51.238 > OK 07:25:51.722 > AT+CIPRXGET=4,0 07:25:51.730 > 07:25:51.731 > +CIPRXGET: 4,0,0

However, the library must be modified to be able to obtain a communication as it does not connect with the original commands.
I think the nb-iot command set in LTE is wrong.

It is also my opinion that an nb-iot device without a hardware reset cannot be used seriously.

Thanks for the helping.

@cocoa invalid header means you are trying to write the wrong UIflow2 firmware version to the wrong device

Hello @cocoa

I am seeing the same Invalid chip error for the M5AtomS3Lite UIFlow2 firmware using M5Burner on Linux. Unfortunately I don't know how to fix that.

If you're up to it you could build UIFlow2 firmware yourself - it's what I did. See here.

Thanks
Felix