Redpitaya Forum

Hi everyone,

In a C / C ++ application, the API is accessed and the signals are captured / processed. From time to time, however, shows the following behavior:

The Red Pitaya - the entire operating system - crashes unexpectedly. Crashing means that I only disconnect the power supply and reconnect, so the device reboots. I can only guess what it can be. Errors such as dividing by 0 or incorrect memory accesses cause runtime errors and the operating system gets these errors. In contrast, the error I describe always occurs when I access the library. Presumably, the library will be accessed in the background in addition to my application, causing a system crash. Therefore I have with following commands e.g. the web interface deactivated:

...
system ("cat /opt/redpitaya/fpga/fpga_0.94.bit> / dev / xdevcfg");
system ("systemctl stop redpitaya_nginx.service");
system ("systemctl stop redpitaya_scpi");
system ("systemctl stop jupyter");

sleep (3);
...

(API access through my application)

Additionally, I put a sleep function behind the commands. Hopefully, this will give me enough time to stop accessing the library when my application accesses it. Sometimes my application runs and the entire system crashes - that is, although several functions of the API have been used several times. My question is: Is any other instance accessing the library at the same time as my application, resulting in a complete system crash? Or. what must be disabled to avoid this problem?



Thank you very much

Martin

Hello Martin
What do you mean with "crashes"?
Does the system lock up like in an endless loop? At least I understood it that way.
I am also using the library and had a few problems myself in the beginning. Meanwhile I have added some new functions in the FPGA and into a new library to extent the functionality of the original "librp".
It sounds to me like an endless loop somehow.
Does the heartbeat LED blink?
Have you tried a different SD-Card?

Regards
Uwe

Hi,

crash means that the entire system crashes. Normally several LEDs flash, after the crash the green LED is permanently on.
Is definitely not an endless loop, because after the crash, the device via ping is not available anymore.

I have tried different SD cards / images. No improvement.

Hi Martin
You have to use the librp that fits the fpga image.
Do not use it from different versions.
They have changed a lot of internal things i.e. the access to the fpga part.
Have you tried a different RP?
Regards
Uwe

Hi Uwe,

what do you mean by "You have to use the librp that fits the fpga image."?
I've run my application on 5-10 Red Pitayas, the same behavior everywhere.
I always followed the instructions below (Github):

https://github.com/RedPitaya/RedPitaya/ ... Examples/C

Hi Martin

What I meant was that the library you are using must fit to the used fpga image.
You can not mix a 0.97 library and a 0.94 fpga image.

I have done my modifications of the fpga to the 0.94 version. Because there are some bugs in 0.94 librp i tried to use the newer from 0.97. I could not get it to work because so many changes have made internally. So now I am using the source for the librp from 0.94 and compile the library myself. Works fine so far.

It can be a PITA to debug problems when using the librp. But I assume there will be problem in your software. Either one of the difficult to track like using wrong pointer or similar.

Do the provided example programs work? Seems you need to track down the error until you find the call that is causing the lock-up.

Regards
Uwe

Hi Uwe,

I think I found a partial solution for the problem.
In the main program I ran the above "system" commands at the beginning. However, I accessed the library in another thread.
Depending on which sequence is running faster, the order of the commands is correct or wrong.

Hi Martin
Seems you ran into a similar problem like I did when I used the I²C bus using different threads. You have to use a semaphore to protect system resources.
I have made myself 2 functions "rpext_I2cBusAllocate" and "rpext_I2cBusFree" to set and release a mutex semaphore. Multithreading can be very difficult sometimes.
Hope that will work for you.
Regards
Uwe