Async API / Two RX channels / Ramdom error on enable modules

[f4gkr]

I'm having random issues working the two RX channels of the Blade A4. Code summarized below, running under Ubuntu 18.04 / bladeRF lib 2.4.0-git-a3d5c55f / FPGA v0.11.0 / FX3 v2.3.1 `` status = bladerf_init_stream(...)
if (status != 0) {
...
}
status = bladerf_enable_module(my_device->sdr_device, BLADERF_CHANNEL_RX(0), true); if (status != 0) { ... }

status = bladerf_enable_module(my_device->sdr_device, BLADERF_CHANNEL_RX(1), true); if (status != 0) { fprintf(stderr, "Failed to enable RX(1): %s\n", bladerf_strerror(status)); bladerf_deinit_stream(stream) ; my_device->error = true ; continue ; }

``

This code works okay for thousands of times and ... sometimes returns error after the second module is enabled :

[ERROR @ host/libraries/libbladeRF/src/board/bladerf2/rfic_host.c:300] _rfic_host_enable_module: dev->backend->enable_module(dev, dir, false) failed: Operation timed out Failed to enable RX(1): Operation timed out

I haven't been able to figure out what happens. Any idea ? Thanks

[pierreduf]

Hello, I've got a very similar issue. Have you been able to pinpoint the cause and find a solution ?

[f4gkr]

Hello,

The trick I've used so far : Add a short delay (some milliseconds) between the different modules enable, it's working fine for 2 weeks of continuous sampling, but ....

sylvain

Le mer. 17 févr. 2021 à 16:12, Pierre DUFOUR [email protected] a écrit :

Hello, I've got a very similar issue. Have you been able to pinpoint the cause and find a solution ?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Nuand/bladeRF/issues/804#issuecomment-780622831, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA6AXMP67BF76WBHYAAUJHLS7PMFXANCNFSM4WOYBL7Q .

[pierreduf]

Hi, thanks for your quick answer. I've tried that (I think) but it didn't do the trick. Maybe I'll try again and see if that's OK. When you say "2 weeks but...." is it because it's still running or you had crashed after 2 weeks ?

I've just tried a new thing and it seems to work also: forcing the tuning mode in FPGA could be solution. I suspect something wrong in the code managing the enabling/disabling of the module when it's done on the host side (rfic_host.c around lines 294)

[f4gkr]

It is still running "like a charm"; I just cannot say that it will not crash again... Ok for the tuning, did not try this one. My conclusion is also that there is a state machine issue somewhere, and by letting some time between the module commands, the State Machines does reach a stable state, but I have not really looked at the FPGA code

Le mer. 17 févr. 2021 à 17:35, Pierre DUFOUR [email protected] a écrit :

Hi, thanks for your quick answer. I've tried that (I think) but it didn't do the trick. Maybe I'll try again and see if that's OK. When you say "2 weeks but...." is it because it's still running or you had crashed after 2 weeks ?

I've just tried a new thing and it seems to work also: forcing the tuning mode in FPGA could be solution. I suspect something wrong in the code managing the enabling/disabling of the module when it's done on the host side (rfic_host.c around lines 294)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Nuand/bladeRF/issues/804#issuecomment-780683415, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA6AXMPP7DUSTDJB2CSBUDLS7PV3VANCNFSM4WOYBL7Q .