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 https://github.com/emard/wifi_jtag/issues/1#issuecomment-106752786.

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

https://github.com/emard/wifi_jtag/blob/bcdeaa67948218d644938305fc9559b85315bfda/lua/jtag.lua#L104

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 https://github.com/emard/wifi_jtag/issues/1#issuecomment-106952970.

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 https://github.com/emard/wifi_jtag/issues/1#issuecomment-107246937.

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 https://github.com/emard/wifi_jtag/issues/1#issuecomment-107330085.

[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.