How to avoid rebooting, when executing longer transfers with lua code.

[wzab]

Hi,
I had similar problem with JTAG interface based on ESP8266 in lua.
The solution is to call tmr.wdclr() periodically in the loop, in which you perform transfers.
HTH & Regards,
Wojtek

[emard]

On Thu, May 28, 2015 at 12:08:28PM -0700, wzab wrote:

Hi,
I had similar problem with JTAG interface based on ESP8266 in lua.
The solution is to call tmr.wdclr() periodically in the loop, in which you perform transfers.
HTH & Regards,
Wojtek

HI Wojtek!

Is wifi_jtag LUA JTAG useable when you add tmr.wdclr()
Works only once or multiple times?
(After one JTAG transfer, will it work again)

Best regards!

[wzab]

I haven't tested your code yet. I've started work on something similar
independently:
https://groups.google.com/forum/#!topic/comp.arch.fpga/Rv8VRcbudEc
https://groups.google.com/forum/#!topic/comp.arch.embedded/Rv8VRcbudEc

However, when testing the performance of Lua based bit shifting, I faced
the same problem.

For transfers longer than 1000 bits, ESP8266 got reset from the watchdog.
So the solution was to clear the watchdog from time to time (every certain
number of bytes).

With best regards,
Wojtek

2015-05-29 11:13 GMT+02:00 emard notifications@github.com:

On Thu, May 28, 2015 at 12:08:28PM -0700, wzab wrote:

Hi,
I had similar problem with JTAG interface based on ESP8266 in lua.
The solution is to call tmr.wdclr() periodically in the loop, in which
you perform transfers.
HTH & Regards,
Wojtek

HI Wojtek!

Is wifi_jtag LUA JTAG useable when you add tmr.wdclr()
Works only once or multiple times?
(After one JTAG transfer, will it work again)

Best regards!

—
Reply to this email directly or view it on GitHub
#1 (comment).

Wojciech M. Zabołotny
My GPG/PGP keys:
standard: 8192R/FE58A848 (0720 9430 85DB 7CCD F4C5 5F1E 5107 91FB FE58
A848)
confidential: 16384R/C76D2FB0 (C4E7 9597 CF22 7B5D 28BF 4656 FED7 A63F
C76D 2FB0)

[emard]

Thanks for the suggestion, i placed tmr.wdclr() in lua
code where I think it might be useful.

xilinx virtual cable wifi implementation would be very nice to have!
Tell me if I can help somehow. Arduino-esp8266 seems running OK

There is SPI in ESP8266 and some JTAG transfers when identical to SPI
could be accelerated using SPI.

[emard]

tmr.wdclr() improved situation. Reboot is prevented but still it
wull disconnects TCP about half minute after successful boundary scan.

On the same hardware the source in arduino folder works correctly..

[wzab]

Please check the documentation for net.createServer:
https://github.com/nodemcu/nodemcu-firmware/wiki/nodemcu_api_en#netcreateserver

The function takes the following parameters:
Parameters

type: net.TCP or net.UDP
timeout: for a TCP server, timeout is 1~28800 seconds, for a inactive
client to disconnected.

As I can see, you don't specify the timeout, so the default value is used.

According to:

https://github.com/nodemcu/nodemcu-firmware/blob/master/app/modules/net.c#L38

https://github.com/nodemcu/nodemcu-firmware/blob/master/app/modules/net.c#L395

it seems, that the default is set for 30 seconds.

So I'd suggest to set higher timeout in

wifi_jtag/lua/jtag.lua

Line 104 in bcdeaa6

srv=net.createServer(net.TCP)

e.g.:

srv=net.createServer(net.TCP, 1000)

Regards,

Wojtek

2015-05-30 0:45 GMT+02:00 emard notifications@github.com:

tmr.wdclr() improved situation. Reboot is prevented but still it
wull disconnects TCP about half minute after successful boundary scan.

On the same hardware the source in arduino folder works correctly..

—
Reply to this email directly or view it on GitHub
#1 (comment).

Wojciech M. Zabołotny
My GPG/PGP keys:
standard: 8192R/FE58A848 (0720 9430 85DB 7CCD F4C5 5F1E 5107 91FB FE58
A848)
confidential: 16384R/C76D2FB0 (C4E7 9597 CF22 7B5D 28BF 4656 FED7 A63F
C76D 2FB0)

[emard]

On Sat, May 30, 2015 at 10:28:12AM -0700, wzab wrote:

Please check the documentation for net.createServer:
https://github.com/nodemcu/nodemcu-firmware/wiki/nodemcu_api_en#netcreateserver

Thanks again !!

I'm not too fluent in nodemcu pecularities so I'm adding at once
your suggestion.

That must be bug in nodemcu or underlying library because jtag
sessions are very active sessions. Normal TCP library should not
disconnect them

But to heck theory, let's try the extended timeout :)

[wzab]

You are welcome. I hope that it helps.
BTW, my nodemcu based XVC server is available at:
https://github.com/wzab/esp-wifi-xvc

However there are some problems with its use:
http://forums.xilinx.com/t5/Configuration/Problems-with-XVC-plugin-both-in-ISE-Impact-and-in-Vivado/m-p/631321

Regards,
Wojtek

2015-05-31 23:10 GMT+02:00 emard notifications@github.com:

On Sat, May 30, 2015 at 10:28:12AM -0700, wzab wrote:

Please check the documentation for net.createServer:

https://github.com/nodemcu/nodemcu-firmware/wiki/nodemcu_api_en#netcreateserver

Thanks again !!

I'm not too fluent in nodemcu pecularities so I'm adding at once
your suggestion.

That must be bug in nodemcu or underlying library because jtag
sessions are very active sessions. Normal TCP library should not
disconnect them

But to heck theory, let's try the extended timeout :)

—
Reply to this email directly or view it on GitHub
#1 (comment).

Wojciech M. Zabołotny
My GPG/PGP keys:
standard: 8192R/FE58A848 (0720 9430 85DB 7CCD F4C5 5F1E 5107 91FB FE58
A848)
confidential: 16384R/C76D2FB0 (C4E7 9597 CF22 7B5D 28BF 4656 FED7 A63F
C76D 2FB0)

[emard]

On Sun, May 31, 2015 at 02:20:04PM -0700, wzab wrote:

You are welcome. I hope that it helps.

I've added the timeout, now its still over 15 minutes
uploading image to altera but so far it didn't disconnect
that is great and it might be possible to opload it all
before half an hour timeout...

BTW, my nodemcu based XVC server is available at:
https://github.com/wzab/esp-wifi-xvc

However there are some problems with its use:
http://forums.xilinx.com/t5/Configuration/Problems-with-XVC-plugin-both-in-ISE-Impact-and-in-Vivado/m-p/631321

Oh super, something is even working for you.
Do you know maybe some other tools that has support
for xilinx virtual cable, e.g. openocd or xc3sprog ?

[emard]

On Sun, May 31, 2015 at 02:20:04PM -0700, wzab wrote:

You are welcome. I hope that it helps.
BTW, my nodemcu based XVC server is available at:
https://github.com/wzab/esp-wifi-xvc

However there are some problems with its use:
http://forums.xilinx.com/t5/Configuration/Problems-with-XVC-plugin-both-in-ISE-Impact-and-in-Vivado/m-p/631321

Now I introduced the long timeout now it doesn't
disconnect but works very slow. Every cca minute
only 3-4 TCP packets are received in a burst and then
silence. I left it working for 30 minutes and gave up

I seems lua didn't send TCP ACK (or should resend it more
often)

[wzab]

Have you checked with Wireshark how the packets are flowing? Maybe this is
something related to buffering of data, either on ESP8266 side or on PC
side?
Maybe this something related to delayed ACK. Sorry but currently I'm not
at the computer, so I can't send more detailed info.
Regards
Wojtek
1 cze 2015 08:58 "emard" notifications@github.com napisał(a):

On Sun, May 31, 2015 at 02:20:04PM -0700, wzab wrote:

You are welcome. I hope that it helps.
BTW, my nodemcu based XVC server is available at:
https://github.com/wzab/esp-wifi-xvc

However there are some problems with its use:

http://forums.xilinx.com/t5/Configuration/Problems-with-XVC-plugin-both-in-ISE-Impact-and-in-Vivado/m-p/631321

Now I introduced the long timeout now it doesn't
disconnect but works very slow. Every cca minute
only 3-4 TCP packets are received in a burst and then
silence. I left it working for 30 minutes and gave up

I seems lua didn't send TCP ACK (or should resend it more
often)

—
Reply to this email directly or view it on GitHub
#1 (comment).

[emard]

On Mon, Jun 01, 2015 at 12:44:24AM -0700, wzab wrote:

Have you checked with Wireshark how the packets are flowing? Maybe this is
something related to buffering of data, either on ESP8266 side or on PC
side?

I've tcpdump'd 'em, 3-4 packets pass in a burst and then silence
Just wanted to ask if you have seen or fixed such problem.

Maybe this something related to delayed ACK. Sorry but currently I'm not
at the computer, so I can't send more detailed info.

[zoobab]

Any idea if UDP could be used instead of TCP to speed things up?

I was also thinking of proting ZMQ to the ESP8266 (wip), so maybe it will help or make things worse in terms of performance.

[emard]

Shure, UDP is much much stable than TCP on esp8266

but openocd remote_bitbang protocol is only TCP
UDP bitbang support should be then added to openocd

or on the host some tunneling from TCP to UDP
could be done with socat or similar tools

UDP as protocol doesn't assure packets will arrive
in the same sequence as they are sent, while wifi_jtag
needs each packet in right sequence.

On higher network load, wifi_jtag may receive UDP
out-of-order or even some packets missing. Handling
this will make code very complex (in fact then we might
end up implementing TCP-UDP encapsulation :)

[zoobab]

You could start with a simple socat trick to transform a local TCP port in a remote UDP endpoint.

[emard]

So far TCP method works good enough for all my boards

<2 minute upload time is really acceptable when
compared to 15 minutes compile time.