Skip to content
This repository has been archived by the owner on Sep 28, 2019. It is now read-only.

Remote Bitbang does not connect on Windows #32

Closed
steveway opened this issue Sep 11, 2018 · 5 comments
Closed

Remote Bitbang does not connect on Windows #32

steveway opened this issue Sep 11, 2018 · 5 comments

Comments

@steveway
Copy link

Description

On Windows OpenOCD does fail after establishing a connection with this message:
Error: fdopen: failed to open read stream

Steps to Reproduce

  1. Start a SocketServer, this minimal Python Example works:
import socket
import sys
import time

PORT = 3335

srv = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
srv.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
srv.bind(('127.0.0.1', PORT))
srv.listen(1)

sys.stderr.write('Waiting for connection on {}...\n'.format(PORT))
client_socket, addr = srv.accept()

sys.stderr.write('Connected by {}\n'.format(addr))
while True:

    data = client_socket.recv(1024)
    if data:
        print(data)
  1. Try to connect to this using OpenOCD, for example with this configuration:
interface remote_bitbang
remote_bitbang_port 3335
remote_bitbang_host 127.0.0.1

set WORKAREASIZE 0x8000
set CHIPNAME lm4f120h5qr
source [find target/stellaris.cfg]
reset_config srst_only

Save that in a file and execute it like this: "path/to/openocd.exe -f /path/to/configfile.cfg"

Expected behaviour:

It should connect and then will spit out the command from OpenOCD, in this case this:
b'BrbBbB262626262626262bB2626260426040401R'

Actual behaviour:

It connects and then quits with this error:
Error: fdopen: failed to open read stream

When running OpenOCD on a Linux Host then it connects successfully, even no matter if the other part is running on Windows or Linux.

Versions

  • OpenOCD package version 0.10.0-8-20180512-1921
  • plug-in version -
  • Eclipse version -
  • Java version -
  • operating system Windows 10
  • toolchain version -
@ilg-ul
Copy link
Contributor

ilg-ul commented Sep 11, 2018

did you try the same with an OpenOCD built from the latest sources?

I'm not maintaining OpenOCD, I'm just packing it from time to time.

@steveway
Copy link
Author

steveway commented Sep 11, 2018

Do you mean with OpenOCD from their Sourceforge page?
I'm pretty sure I tried the most recent download from there but it seems that it does not even include the remote_bitbang option.
That's why I tried this one, since this project seems to carry more up-to-date binaries and remote_bitbang is included.

@ilg-ul
Copy link
Contributor

ilg-ul commented Sep 11, 2018

Do you mean with OpenOCD from their Sourceforge page?

yes

it does not even include the remote_bitbang option

I don't know who authored this feature, if it is not in the master branch, it might come from the RISC-V fork.

anyway, there is little I can do to fix it.

@steveway
Copy link
Author

I think we misunderstood each other.
The master branch does include remote_bitbang as an interface driver.
It's even mentioned in the documentation:
http://openocd.org/doc/html/Debug-Adapter-Configuration.html#Debug-Adapter-Configuration

I just tested and the binary that did not even include this was compiled from a different author on Github, because it has this in it's header: [https://github.com/sysprogs/openocd]
The OpenOCD project itself does not seem to provide any binaries if I see this correctly.
I did not yet try to compile this myself, the idea was for my script to be able to use the commonly available binaries, which would be yours as far as I can see.

Btw, the working version I used under Linux (Ubuntu 17.10 in this case) is 0.10.0 directly from their repositories.

@ilg-ul
Copy link
Contributor

ilg-ul commented Sep 11, 2018

the working version I used under Linux (Ubuntu 17.10 in this case) is 0.10.0 directly from their repositories

in this case you should compare exactly the same version with the Windows release; comparing different versions makes not much sense.

if the problem is in the sources, and the latest OpenOCD sources include a fix for this issue, probably my next release will be functional too.

if the latest sources work on Linux but fail on Windows, my next release will behave the same, since I generally do not add changes myself (except when absolutely necessary, like integrating patches for RISC-V)

@ilg-ul ilg-ul closed this as completed Sep 11, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants