For Snapdragon Flight:
See thread for similar issues: Problems starting muorb on Snapdragon flight
Ignore my post in there.
The error is ERROR [muorb] Error: Getting Bulk data from fastRPC link.
I have heard that this means that the DSP-side PX4 app has crashed.
My aDSP firmware is the latest version, so that is not the problem. Sometimes the program runs fine, and sometimes it doesn’t, which means it is likely a race condition.
My module starts two threads. Main starts thread1, and thread1 starts thread2. I notice that the above error occurs when I put more things into thread2 (One example of this is when I print too often). This substantiates the race condition theory (again, sometimes it runs fine). Unfortunately some of this is opaque to me (thru lack or knowledge or proprietary software), which makes debugging extremely difficult. For example, mini-dm, Snapdragon shared memory access, and PX4 multi-threading on Snapdragon. Threads are started with px4_task_spawn_cmd(). Adding sleep statements on thread start or on program start thru px4_config file doesn’t help.
CMake params:
STACK_MAIN: 600 (shouldn’t matter b/c main just starts a thread then quits)
STACK_MAX: 3600
Thread1 params:
stack size: 1800
priority: SCHED_DEFAULT_PRIORITY
Thread2 params:
stack size: 2000
priority: SCHED_DEFAULT_PRIORITY+30
Any debugging tips or obvious solutions that I’m missing?
Edit:
It looks like it may not be a muorb error, but an error with whatever is putting data into muorb. This theory substantiated by the error [get_bulk_data] ERROR: Semaphore is up when there is no data in the control/data queues
Edit2:
Seems the problem was reading from files DSP-side. I figured out a while ago by guessing directory structure there’s a way to auto-load files onto the DSP (I assume at runtime). Took for granted that this was stable, but it seems to cause many errors. Possibly b/c QuRT/shmem string methods are slow, possibly due to file size (although it is only a few lines text file), possibly due to some missed step in logging file during PX4 environment load, possibly something entirely different. Any clues as to a solution would be interesting, but not necessary.