Baremetal peripheral interaction via the SDSP

Alexandre Pabouctsidis

Hello,

In order to get a better grasp of the voxl2 module, i'm trying to develop a very basic test code from scratch, starting from the qualcom demo code + inspiration from the PX4 cmake, etc.

I've reached the stage where I can build the ARM app + DSP lib, load it on the DSP and run it.

I'm now trying to interact with the SPI+USART+GPIO(?) peripherals. I've spent countless hours digging through the px4 code base, dspal, etc. but I'm having trouble finding the absolute low level code which actually interacts with the peripheral/HW.

Could someone show me where in the code base is the actual implementation of the SPI or USART transfer (and not just one of the many, many hardware abstractions )

After following the chain, the lowest i got is that the spi/usart functions are passed to the _muorb__slpi module, which are initialized through "px4muorb_orb_initialize", which should be called by the apps processor? but i can't find any instance of where it's done. etc.

The first goal is to read the whoami register of the icm, without any of the HALs (dspal, etc.)

Thanks for the help!
Alex

Chad Sweet

Hi Alexandre,

Impressive start to your development!

We will find that pointer and let you know where the SPI, UART are called.

Eric Katzfey

@Alexandre-Pabouctsidis The DSP runs an OS called QURT. This OS provides IO services to applications running on it so that they can access I2C, SPI, UART, and interrupts. Unfortunately, all of that code is Qualcomm Proprietary and so we have had to abstract it into the function calls that you see bound to PX4 in muorb. Everything below that is built into our DSP image and cannot be shared to non-QC licensees.

Chad Sweet

@Alexandre-Pabouctsidis this might be helpful for what you are trying to do:

-> ICM42688P whoami register read code
--> ICM42688P::RegisterRead
---> SPI::transfer
----> light-weight callback into DSP OS to perform _spi_transfer

Alexandre Pabouctsidis

Thanks for responding. Is this proprietary code the Qualcom Hexagon SDK?

I'm already building the DSP code with QuRT, but it's unclear how to do the system calls in order to interact with the devices.

For example, i've tried this to blink a LED:

int fd; 
fd = open("/sys/class/gpio/gpio1182/value", O_WRONLY);
if (fd == -1) {
    FARF(ALWAYS,"Unable to open /sys/class/gpio/gpio1182/value");
    qurt_thread_exit(QURT_EOK);
}

// Toggle LED 50 ms on, 50ms off, 100 times (10 seconds)

for (int i = 0; i < 100; i++) {
    if (write(fd, "1", 1) != 1) {
        FARF(ALWAYS,"Error writing to /sys/class/gpio/gpio1182/value");
        qurt_thread_exit(QURT_EOK);
    }
    qurt_timer_sleep(50000);

    if (write(fd, "0", 1) != 1) {
        FARF(ALWAYS,"Error writing to /sys/class/gpio/gpio1182/value");
        qurt_thread_exit(QURT_EOK);
    }
    qurt_timer_sleep(50000);
}

close(fd);

It builds and runs but nothing happens.

as for the SPI, the hexagon system libraries don't contain headers for <sys/ioctrl.h>. I noticed in the PX4, the headers are defined in the DSPAL, and the implementation is in dspal_imp.c (https://gitlab.com/voxl-public/flight-core-px4/px4-firmware-ci/-/blob/v1.4.20-modalai-rb5-flight-beta/platforms/qurt/src/px4/common/dspal_impl.c), but are just stubs?

Chad Sweet

I believe you should be accessing gpio1182 from the Linux CPU.

The DSP portion has a partitioned subset of the I/O needed for flight control. The rest should be accessed from the CPU. The two are kept separate on purpose so the DSP can keep running if the CPU is bogged down or has an issue.

Eric Katzfey

@Alexandre-Pabouctsidis The IO mapped to the DSP is not directly accessible using the SDK. It's at a lower layer that isn't exposed to "guest" applications.