Hello Try doing a "telnet xxx.177.143.xxx 7130", issuing a "log-level debug" and then re-running your code, while keeping that telnet session open.
With a bit of luck it should provide some feedback. Running multiple instances of tcpborphserver can be problematic - for one the register names are local to each process, and so could get out of sync. Other problems may occur too. regards marc On Mon, Dec 9, 2024 at 3:27 AM Ken Semanov <shapkiqua...@gmail.com> wrote: > A call to read_raw( ) eventually flows execution to within the method > calleddef katcprequest( ) located in the following file, (236) > https://github.com/casper-astro/casperfpga/blob/master/src/transport_katcp.pyTherein > <https://github.com/casper-astro/casperfpga/blob/master/src/transport_katcp.pyTherein>, > self.blocking_request() is called at 261. The returned > 'reply > > > > > > > > > > > > > > > > > > > > > > > > > > > <https://report.mimecastcybergraph.com?magiclink=https%3A%2F%2Fapi.services.mimecast.com%2Foauth2%2Fauthorize%3Fresponse_type%3Dcode%26client_id%3Do20nRkVXf7VUVnANkXhoOwGytEwGN0YAlyeDJn7oBTGNl2kN%26state%3DeyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMjU2R0NNIn0.VdG9KH6ZRWmC7dee5dar2OGTeOcPp5s0QFzcG48rwnG4OqXECeZ9ybIkS65bX4iC1EtCjF2i-Db-yPNtBsWslx0KEdYEjnJa4BNHLdA1kCkvZojCk0SWZ4QlMB2ABIQqnY1xG3zYYTK4G_a_dKIrVIvcPo0c9gS-P4ua0nWLvDG0bk8ZKji8Cq1l-GKNF2icycEDIMCdFu2CCjTjC7Sdo4_j0mBXovzdJVH1FKuhGzoeWgAZorVgj3a31C4rb8cGzyd8Dl8_aZ03kJNKaRCI3IxCkOLp3QikQqoAaxyYcqCUPPhttyUyNul_BQ9r7GZuViLyCvW2G586KYyqJyFpcg.wXiCGni5QtEUeMXd.U5r5KenZ6X7uB44WdkZL1E1w14s3M44eMZlkeFhDTZFvM1ho4Hho_C9PMcjp1oNoY8815lhwRMycsE3uzd3v1nppY55XUp-Wx-S89d9_2DY_udFkG6czmZzqXMfZGR-TyRE05_KIFePWghe7UJ8XvKzgqe3y3AmJuawtDT3MVTOSXJEK84MTyv8PgoiWhcMgqyTBKhsifI7Rq5n0DFV7WTY3glSCqSUNUrSZdxVvzCLcvgpxzGihcVq1jJu_6wvkA-Rh0T1BBGAcV_spAVIfmASIPMZ4gWJuCqEaBI-F9VUYs8Eww_1ZtbzP5tU72VVFGgp0bAsh6grXDOpD_e4NWrDMHFXb6xXviEDoJFRelYotTmdrpX9QgvIabrB6Rd_HuQPLstyVfVN5jITtXVgcqVn7_EfhOEg_pn3Ce6YwvMBtqMEzf3VQ3kdkgjyQ2u6MM0rE7gQVizDSHysLzacrgSSf8qb19zg19XqiGB1SeRKu1asdFKKxNKJf6B7KGjLGeym3m4_lxJA0HBN8aRRGEKjBbX3_SMdIU1SjZwzYNBpmZ9dtUHsjH_kiszpYVhWd5gWk0RrD8Hw0RpG0Ib3DT35qZ8A7ZxW8GiD5pLu9ef1HdtKacLM0nET6GXH8YL1VcIQUMB2OMnI0XUolIvpgGAZvb7xVX-POuONoRXeuhLkGK4DaYQfcLH9r71j6eUm-njUj2jvg2nToa8vU3BBWgnjkYJiT2LuIv5Km8vryIbT96YYgRPywFrHrXqlso3IGRsiLna3Xvc0iIUkrug831dlh6tVQElbgVm8SkLMapkLmPzL4bPVATSVCBzwbxhWatMBu4ZUAVQ.lbY3h_UMRuf_R3npnT2r6A%26redirect_uri%3Dhttps%3A%2F%2Freport.mimecastcybergraph.com%2Fcallback> > CGBANNERINDICATOR > A call to read_raw( ) eventually flows execution to within the method > called def katcprequest( ) located in the following file, (236) > > > https://github.com/casper-astro/casperfpga/blob/master/src/transport_katcp.py > <https://github.com/casper-astro/casperfpga/blob/master/src/transport_katcp.py> > > Therein, self.blocking_request() is called at 261. The returned 'reply' > raises the exception on line 266. > > > - File > > "/home/xpswhite/cfpga/casper_venv/lib/python3.8/site-packages/casperfpga-0.4.4.dev1336+py38.276ee44-py3.8-linux-x86_64.egg/casperfpga/transport_katcp.py", > line 297, in katcprequest > - raise KatcpRequestFail( > - casperfpga.transport_katcp.KatcpRequestFail: Request write on host > xxx.177.143.xxx failed. > - Request: ?write counted_capt_buffer_ctrl 0 \0\0\0\0 > - Reply: !write fail > > > I am currently using a tcpborphserver3 listening on port 7130. This > differs from the default port of 7147 > > > - $ ps aux | grep tcp > - root 497 1.0 0.0 5804 3108 ? Ss May25 5:24 > /bin/tcpborphserver3 -b /lib/firmware > - root 1087 0.0 0.0 3692 1896 ? Ss 00:45 0:00 > /bin/tcpborphserver3 -b /lib/firmware -p 7130 > - casper 1319 0.0 0.0 5832 684 ttyPS0 S+ 03:24 0:00 > grep --color=auto tcp > > > If the above write error is suppressed, the code errors in the same place > with reads. The client is able to connect just fine to port 7130, but > these reads and writes to software registers fail in the following way > shown above. The content of the request "looks" to be just fine. During > reads, it actually returns the number 4 in the reply, which is correct. So > something else is populating errors in re > > A possible fix here is to inform the blocking_request() call with the new > port I am using. Is there a way to inform this call with the particular > port? > > Another possible fix is that port 7130 must be let through a firewall on > the SoC board. > > Your thoughts? > > -- > You received this message because you are subscribed to the Google Groups " > casper@lists.berkeley.edu" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to casper+unsubscr...@lists.berkeley.edu. > To view this discussion visit > https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/79eb0468-fe39-44a4-86f2-4fd9dcef47d5n%40lists.berkeley.edu > <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/79eb0468-fe39-44a4-86f2-4fd9dcef47d5n%40lists.berkeley.edu?utm_medium=email&utm_source=footer> > . > -- The use of google poses numerous <https://jwz.org/xscreensaver/google.html> grave privacy risks Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+unsubscr...@lists.berkeley.edu. To view this discussion visit https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAGrhWaRN3txNgP8YL2_ci1Qsu-7Shug1vMy%2BSk_B8kAftxreyw%40mail.gmail.com.
