#94 TCP support

[Lesto]

Hi,
i-m working on uploading the firmware over TCP (ESP8211), so far I am using the serial upload, creating a serial to TCP bridge with socat; the the ESP8211, acting as server, will do the opposite work. Baudrate is fixed at 57200 8E1 for semplicity.

I had to disable the check on serial port flag, as they fail on the virual serial created by sockat; this seems to create some issue, as i am able to upload firmware but only if NOT verifing the content! also it start the execution by -b 0x0

Also tested the get of information alone, and sending different command using -c to avoid reinitialization, and seems to work BUT

The upload with verification seems that i fail after a fixed amount of bytes, and always because the chip STOP from sending data. I "sniff" the data output by the chip, and it is the STM32 that stop to send data during the verification, and it always seems to hang at the 132 byte read from the flash.

Any idea where the issue could come from? The ESP Serial says to have 128 byte HW FIFO + 256byte of buffer, so I don't think to be the problem. (edit: seems like the software buffer has been disabled, but re-enabled in the git version, building it tomorrow)

Also seems i managed to brick one of the chip im using, but as that board is not fully open i still have to understand f they use HW bootloader.. Anyway it does not seems to anser to any message, even if i write manually the 0x7F using a terminal and different baudrate. The serial port work correctly bidirectionally if used by a script uploaded by USB DFU... maybe some of you have already encounter a similar situation and manage to get out of it.

[Lesto]

sorry guys, finally compiled the new firmware from ESP with software buffer of 1024 byte and upload with verification works!

Also did a qauick test on the "bricked" board and worked first time!!

here the complete setup:

1. from serial_posix.c comment out (maybe the dev should make this optional eabled by default?)
   tcgetattr(h->fd, &settings);
   if (settings.c_iflag != h->newtio.c_iflag ||
   settings.c_oflag != h->newtio.c_oflag ||
   settings.c_cflag != h->newtio.c_cflag ||
   settings.c_lflag != h->newtio.c_lflag)
   return PORT_ERR_UNKNOWN;

2. on the ESP load the following code, compiled with the git version (latest arduino stable core is 2.3.0 and wont work) and connect the esp to the chip
   https://github.com/MauroMombelli/ArduinoRepo/blob/master/ESPLOOPBACK/ESPLOOPBACK.ino

3. start the virtual serial bridge over TCP with socat
   sudo socat PTY,link=/dev/ttyS0,echo=0 tcp:192.168.178.123:1234

4.profit!!
./stm32flash -w ReadSensor2.hex -v -g 0x0 /dev/ttyS0

[Tormod Volden]

That's cool. So the tcgetattr() check fails on the virtual serial port created by socat? We could maybe make that check less fatal.

[Lesto]

exactly, I commented out all the if, but i guess an attribute to
disable the check would be a much better solution, with the check
enabled by default.. just to retain compatibility with existing
script.

This method need socat, so maybe one day someone will build a proper
socket support.. but so far is a nice hack and works properly and more
reliably than i was expecting, so far i got no problem (last famous
word?)

I think this is a great feature as this chip are often embedded in
drones and rover, that would make possible to use one interface to
program and communicate with the chip in any environment and for
extremely cheap cost; the ESP chip is 2-5€, and can operate as AP or
as a WiFi client.

My plan is to adapt the current script to run as Client by default if
configured; if not configured or the connection fail (wrong psw, no AP
in range etc) it default to AP mode, so if you are home you can
program and surf the internet, and if you are outside you retain all
the functionality without any modification.

As foolproof as possible!

[Tormod Volden]

Does the tcgetattr() call above fail or are the flags in "settings" not matching? All flags or some?

[Lesto]

fprintf(stderr, "i %d %d, o %d %d, c %d %d, l %d %d\n",
settings.c_iflag, h->newtio.c_iflag,
settings.c_oflag, h->newtio.c_oflag,
settings.c_cflag, h->newtio.c_cflag,
settings.c_lflag, h->newtio.c_lflag
);

gives

i 16 16, o 0 0, c 6322 6578, l 16 16

so only the flag c_cflag is not not properl set; in particular is only the 9 bit, with i think rapresent OFILL. Can we set to ignore it? maybe disable the checks by a parameter?

[Lesto]

bump

[Tormod Volden]

This should be fixed by https://sourceforge.net/p/stm32flash/code/ci/48231f15992b48f3694fe895bafc8108aeb0cd4c/ which was included in stm32flash release 0.7.