Hi Armin,

You can reset X3x0 series devices via a register write with the following
command (this is in to your UHD src directory):
firmware/usrp3/x300/x300_debug.py --addr 192.168.40.2 --poke=0x00100058
--data=1.

When you kill your app and resume, how long do you wait before restarting?
Can you try waiting a minute or two and see if that fixes the issue? If
that works, then it points to some internal buffering in the USRP not being
cleared before restarting streaming.

Jonathon

On Wed, Feb 20, 2019 at 6:27 PM Armin Schmidt via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hm, does someone know if it is possible somehow to reset the FPGA over a
> register? We see, that there exists a registers for resets of different
> modules (SR_SW_RST), but don't know, if we could use this over the API.
> Does somewhere exist a register-map? I think that should be the basis of
> every documentation.
>
> Would be quite sad, if Ettus don't prioritize the possible to use the
> hardware for real operation and not only for tinker-projects. We are
> operating at the moment three systems, each with five x310 and
> ubx-160-doughterboards and in the next several months/years it will be a
> lot more. So I hope Ettus will see this conversation and respond, otherwise
> we will be forced to move on to other vendors! The Ettus-support is quite
> painful and slow from my experiences and the documentation even worse!
>
> Am Di., 19. Feb. 2019 um 20:45 Uhr schrieb Brian Padalino <
> bpadal...@gmail.com>:
>
>> On Tue, Feb 19, 2019 at 12:07 PM Armin Schmidt <schm...@gmail.com> wrote:
>>
>>> Thanks for your replay! Hm, yes I've thought also about to use
>>> STREAM_MODE_STOP_CONTINUOUS, but I would like to be able to restart my app
>>> also after a crash. Ok, it should never happen, but one can never guarantee
>>> that case. Do you have an idea, how to deal with such cases? I think it's a
>>> bug in UHD, because in the version 3.9 was that never a problem.
>>>
>>
>> From my conversations with Ettus, getting the radios to a known good
>> state after a crash is not something they are prioritizing.
>>
>> My recommendation to you is that you reload the FPGA over JTAG every time
>> before starting your application such that it is always in a known
>> good/initial state.
>>
>> Brian
>>
>>> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Reply via email to