SPI 3 external bus issue on RDDRONE-FMUK66

[MatthiasViertler]

I'm one of the NXP HoverGames participants and @igalloway asked me to open this bug report here in order to get support and make other HoverGames participants aware that we have an issue integrating the Pixy2 cam via SPI3 (2), the external SPI bus.

When adding the Pixy2 src code from here https://github.com/NXPHoverGames/PixyCam we first had to get rid of a hard fault caused by a missing call to m_link.init() in the TPixy2.h file's TPixy2::init(uint32_t arg) method: template <class LinkType> int8_t TPixy2<LinkType>::init(uint32_t arg) { // uint32_t t0; int8_t res; res = m_link.init(); if (res < 0) { return res; } res = m_link.open(arg); ... }

After that, we now successfully execute the Pixy2 code and PX4 notifies us with the component being opened on the SPI bus 3 but we never receive a reply from the Pixy2 and its LED also never turns on (see screenshot).

When scoping using an Osci, we can see that the CS/SS never goes LOW (SELECTED) despite the respective SPI_SELECT() call inside NuttX's SPI::_transfer() method being clearly made on the right SPI bus 3 with the correct _dev handle pointing to g_spi2dev. This cannot be seen on below screenshots but we saw the CS/SS always being at 3.3V and never dropping, while it should be switching very frequently between LOW/HIGH for every byte being sent. When forcing the SPI3 CS/SS to LOW via GND we can suddenly see the Pixy2 turning on and the status LED turning red (probably indicating a protocol issue since CS/SS is supposed to be LOW/HIGH for every byte).

We also see a very noisy signal on all SPI3 output pins of our FMUK66. See further screenshots:

Please note, all other SPI components on SPI1 (Memory) and SPI2 (Sensors) is working fine for us. Hence, the SPI PX4/NuttX driver is obviously fine.

I don't think it's a PX4/NuttX issue but rather caused by either a HW issue on FMUK66 which exists only on external SPI3 or a FMUK66 porting issue where the wrong SPI/GPIO pin is controlled instead of the CS/SS pin of SPI3.

When debugging into the PX4 / NuttX code I can see that it ultimately ends up at kinetis_gpiowrite() inside kinetis_pingpio.c, trying to write to GPIO pin as described below. Also see screenshots here: and

GPIO pin value for Pixy2 = 0x1300 030F (318767887) port=3 (where KINETIS_NPORTS == 5) base= 0x400F F0C0 (1074786496)

Defines from NXP FMUK66's board_config.h:

define GPIO_SPI2_CS (GPIO_LOWDRIVE | GPIO_OUTPUT_ONE | PIN_PORTB | PIN20)

define GPIO_SPI2_EXT (GPIO_LOWDRIVE | GPIO_OUTPUT_ONE | PIN_PORTD | PIN15)

Our next steps include ordering a 2nd FMUK66 to rule out an issue which is only present on our board and NXP's FMUK66 RDDRONE board architect to look into potential HW problems with SPI3. @igalloway also sent an email to our NuttX consultant who did the Pixy2 code porting.

[igalloway]

@davids5 could you have a look at this?

[davids5]

@igalloway @MatthiasViertler

To test this bus I added the pmw3901 to the build to test. (see below)

nsh> pmw3901 -b 3 start PMW3901 on SPI bus 3 at 0 (2000 KHz)

diff --git a/boards/nxp/fmuk66-v3/default.cmake b/boards/nxp/fmuk66-v3/default.cmake
index b6901eb731..f7af1ec4e4 100644
--- a/boards/nxp/fmuk66-v3/default.cmake
+++ b/boards/nxp/fmuk66-v3/default.cmake
@@ -38,6 +38,7 @@ px4_add_board(
                magnetometer # all available magnetometer drivers
                mkblctrl
                optical_flow/px4flow
+               optical_flow/pmw3901
                pca9685
                #pwm_input # NOT Portable YET drivers
                pwm_out_sim
diff --git a/src/drivers/optical_flow/pmw3901/PMW3901.hpp b/src/drivers/optical_flow/pmw3901/PMW3901.hpp
index 35d0009c37..a98d854550 100644
--- a/src/drivers/optical_flow/pmw3901/PMW3901.hpp
+++ b/src/drivers/optical_flow/pmw3901/PMW3901.hpp
@@ -68,6 +68,8 @@
 # define PMW3901_SPIDEV PX4_SPIDEV_EXTERNAL1_1
 #elif defined PX4_SPIDEV_EXTERNAL   // fmu-v4 extspi
 # define PMW3901_SPIDEV PX4_SPIDEV_EXTERNAL
+#elif defined PX4_SPIDEV_EXTERNAL1   // fmu-k66 extspi
+# define PMW3901_SPIDEV PX4_SPIDEV_EXTERNAL1
 #else
 # error "add the required spi dev from board_config.h here"
 #endif

The code and HW is performing as I would expect.

[igalloway]

@MatthiasViertler have you been able to test David's code? Perhaps you have a hardware issue.

[MatthiasViertler]

@igalloway: There's no code to test from David - all he's showing here is that he is able to get a PMW3902 component to work on the FMU-K66 using the external SPI bus 3 macro "PX4_SPIDEV_EXTERNAL1".

We're already using this in our Pixy2 SPI driver as well - see below code which is from the Pixy2 repo provided by your team:

PIXY2_SPI::PIXY2_SPI() : SPI((const char *)"PIXY2_SPI", (const char *)"/dev/pixy2", PX4_SPI_BUS_EXTERNAL, PX4_SPIDEV_EXTERNAL1, SPIDEV_MODE3, PIXY_SPI_CLOCKRATE) { _external = true; }

A potential HW-issue as root-cause has also been eliminated by now: Audrey successfully ran a NXP SDK for K66 on our FMU, scoping a correct SPI CS signal. My best guess was that the issue is related to a wrong GPIO Pin translation for SPI bus 3 but this has also been eliminated by @davids5 through this post.

So I'm basically out of ideas for the moment and also didn't have time to work on it in over a week now.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

[Halo78]

some news from this ? Having troubles to connect the pixy2 via spi