SoapySDRServer on bbb

[Coburn]

Hi All,

I am trying to get a remote SoapySDR and hardware running on a Beaglebone Black.  I have a dummy hardware library of functions written that SoapySDRUtil probes correctly on the bbb.  But when the library is exposed with SoapySDRServer, SoapySDRServer dies if probed remotely with this error message:

SoapySDRServer –bind=“192.168.1.130”
SoapyServerListener::accept(192.168.1.139:50267)
terminate called after throwing an instance of 'std::system_error'
what(): Invalid argument
Aborted

SoapySDRUtil –probe=“remote=192.168.1.130”
probe device remote=192.168.1.130
[ERROR] SoapyRemote::find() – transact FAIL: SoapyRPCUnpacker::recv(header) FAIL:

Does probe interact differently with the hardware library when used remotely and is exposing a silly mistake in my library?  Has anyone used Soapy on the Beaglebone Black and discovered an oddity?  I need to split this problem in half somehow.  Any suggestions would be most welcome.

I have a significant amount of time logged playing with Pothos GUI and what an incredible piece of software.  I look forward to writing my first block.  Thanks Josh.

Best Regards,

Coburn.   

[Josh Blum]

On 09/24/2015 08:28 PM, Coburn wrote:
> Hi All,
>
> I am trying to get a remote SoapySDR and hardware running on a Beaglebone
> Black. I have a dummy hardware library of functions written that
> SoapySDRUtil probes correctly on the bbb. But when the library is exposed
> with SoapySDRServer, SoapySDRServer dies if probed remotely with this error
> message:
>
> SoapySDRServer –bind=“192.168.1.130”
> SoapyServerListener::accept(192.168.1.139:50267)
> terminate called after throwing an instance of 'std::system_error'
> what(): Invalid argument
> Aborted
>
> SoapySDRUtil –probe=“remote=192.168.1.130”
> probe device remote=192.168.1.130
> [ERROR] SoapyRemote::find() – transact FAIL: SoapyRPCUnpacker::recv(header)
> FAIL:
>
> Does probe interact differently with the hardware library when used
> remotely and is exposing a silly mistake in my library? Has anyone used
> Soapy on the Beaglebone Black and discovered an oddity? I need to split
> this problem in half somehow. Any suggestions would be most welcome.

Hey Coburn,

The interaction, as in the calls being made should be the same
concerning probe (locally or remotely). If its a helpful data point -- I
have tested SoapyRemote with the Novena + RF board to my amd64 machine.
However, while testing this, I did catch a typo 4 days ago that only
manifested on the novena and not the pc. So make sure that your repo
checkout is up to date.

Exceptions should safely make their way to the local end, so this seems
to be a little segfaulty. Its also possible one of the dummy functions
you mentioned doesn't implement a return value when it should -- maybe
that segfaults on the remote app, but we get lucky when its a local probe.

Probe calls quite a lot of functions, so its probably best to know which
one was the culprit. I recommend running with the server with gdb, or
apply this diff for soapy remote will tell us the last function that was
called: http://pastebin.com/JCfvHyEL

>
> I have a significant amount of time logged playing with Pothos GUI and what
> an incredible piece of software. I look forward to writing my first block.
> Thanks Josh.

Thanks, I appreciate it.

-josh

>
> Best Regards,
> Coburn.
>

[Josh Blum]

>>
>> SoapySDRUtil –probe=“remote=192.168.1.130”
>> probe device remote=192.168.1.130
>> [ERROR] SoapyRemote::find() – transact FAIL: SoapyRPCUnpacker::recv(header)
>> FAIL:
>>

I didn't read carefully. According to this error, SoapyRemote::find() is
failing, which should be the first call into the remote device. So two
suggestions:

1) put a bunch of prints in the find function for your Soapy SDR module,
and see if its getting there and how far its getting into the call.

2) run it with --probe="remote=192.168.1.130, remote:driver=driverName"
to narrow down the probe to just the module that you are working on.

-josh

[Coburn]

Hi Josh

I can probe and find using SoapyRemote without problems now.

Your suggestion of using gdb and you intuition of the problem feeling segfaulty allowed me to isolate my problem to the SoapyServerTheadData destructor.  I wrapped thread->join() and delete thread in a check for nullptr.  This must be somehow related to the distribution or libraries used on the BeagleBone, and may be as easy to fix as adding a compile option to the makefile. 

I would be very happy explore any thoughts you might have to find why this anomaly shows up on bbb.

On an entirely different tact, as i develop my hardware function library that Soapy calls into, how much of my threading will i be able to rely on soapy for.  IE, is it conceivable to have a usable library with no thread code at all?

Thank you for the help.  I was really starting to flounder there.

Coburn 

[Josh Blum]

On 09/26/2015 12:22 PM, Coburn wrote:
> Hi Josh
>
> I can probe and find using SoapyRemote without problems now.
>
> Your suggestion of using gdb and you intuition of the problem feeling
> segfaulty allowed me to isolate my problem to the SoapyServerTheadData
> destructor. I wrapped thread->join() and delete thread in a check for
> nullptr. This must be somehow related to the distribution or libraries
> used on the BeagleBone, and may be as easy to fix as adding a compile
> option to the makefile.
>
> I would be very happy explore any thoughts you might have to find why this
> anomaly shows up on bbb.

The TheadDatas are stored in a std::map, I think on some implementations
of the stl, a instance of TheadData is getting default constructed,
assigned, and later destroyed -- without ever getting its thread
initialized, hence the error.

It may not even be a bug. And so TheadData wasn't being very robust in
how it was implemented. This is probably the right fix. Thanks for
finding that, I pushed the fix.

>
> On an entirely different tact, as i develop my hardware function library
> that Soapy calls into, how much of my threading will i be able to rely on
> soapy for. IE, is it conceivable to have a usable library with no thread
> code at all?
>

Most of the hardware libraries and the corresponding Soapy wrappers
don't have any thread code at all. Generally the calling code for
read/writeStream is actually performing the work in terms of dealing
with the buffers and the underlying transport or dma. I have only really
seen threads with libusb based devices -- because thats just how libusb
works.

Some client programs will call into various configuration settings from
multiple threads, so its probably worthwhile to put mutex locks into
either the configuration calls or the spi/i2c code -- or whatever it
takes to make it robust against a multi-thread configuration race condition.

Something else that you might want to look at. There are actually two
stream APIs, the read/writeStream and a direct buffer access API. Quite
a few boards implement the direct buffer access calls, and then make the
read/writeStream just a simple wrapper on top of the direct access.

Just mentioning it because embedded boards are usually a good use case
for this feature -- and client code may want to spare the extra cycles
used to convert or memcpy the buffer and just use it hot and fresh off
the DMA.

Example:
https://github.com/myriadrf/Novena-RF/blob/master/driver/host/Streaming.cpp

-josh