Segmentation Fault when calling certain functions

[Zacharyprime]

This is on the refactor branch.

I get a segfault when trying to run a program containing a motor function.
It occurs when calling the function WombatDevice::transfer

(gdb) backtrace
#0  0x76a2852c in WombatDevice::transfer(unsigned char const*, unsigned char*, unsigned int) () from /lib/libkipr.so
kipr/libwallaby#1  0x76a28254 in WombatDevice::w8(unsigned char, unsigned char) ()
   from /lib/libkipr.so
kipr/libwallaby#2  0x76a26b4c in kipr::core::Platform::writeRegister8b(unsigned char, unsigned char) () from /lib/libkipr.so
kipr/libwallaby#3  0x76a4282c in kipr::motor::set_motor_mode(unsigned int, unsigned char) ()
   from /lib/libkipr.so
kipr/libwallaby#4  0x76a3eb20 in move_at_velocity () from /lib/libkipr.so
kipr/libwallaby#5  0x76a3eb60 in mav () from /lib/libkipr.so
kipr/libwallaby#6  0x76a3efbc in motor () from /lib/libkipr.so
kipr/libwallaby#7  0x000105c8 in main ()

This is the file those last functions are defined in.
https://github.com/kipr/libwallaby/blob/refactor/module/core/src/device/wombat/wombat_device.cpp

I thought maybe it could be something wrong with the STM32 since I had some troubles with that earlier.
But analog functions are working fine so the communication with STM32 is not broken.

[Zacharyprime]

Servos also cause segfault

0x76a2852c in WombatDevice::transfer(unsigned char const*, unsigned char*, unsigned int) () from /lib/libkipr.so
(gdb) backtrace
#0  0x76a2852c in WombatDevice::transfer(unsigned char const*, unsigned char*, unsigned int) () from /lib/libkipr.so
kipr/libwallaby#1  0x76a28308 in WombatDevice::w16(unsigned char, unsigned short) ()
   from /lib/libkipr.so
kipr/libwallaby#2  0x76a26d50 in kipr::core::Platform::writeRegister16b(unsigned char, unsigned short) () from /lib/libkipr.so
kipr/libwallaby#3  0x76a44df4 in kipr::servo::set_servo_position(int, unsigned short) ()
   from /lib/libkipr.so
kipr/libwallaby#4  0x76a44b44 in set_servo_position () from /lib/libkipr.so
kipr/libwallaby#5  0x00010668 in main ()

Maybe the STM32 is refusing write to it's memory, but the flashing process is working.

[Zacharyprime]

The equivalent in pre-refactor: https://github.com/kipr/libwallaby/blob/master/src/wallaby_p.cpp

I had been assuming that this file was identical, which would mean that the surrounding code or hardware would have to be the issue, but this was actually changed quite a bit.

Storing this for reference:

private:
  bool transfer(
    const std::uint8_t *const write_buffer,
    std::uint8_t *const read_buffer,
    const std::size_t size
  )
  {
    std::lock_guard<std::mutex> lock(mut_);

    struct spi_ioc_transfer xfer;
    memset(&xfer, 0, sizeof xfer);

    xfer.tx_buf = (unsigned long)write_buffer_;
    xfer.rx_buf = (unsigned long)read_buffer;
    xfer.len = size;
    xfer.speed_hz = 16000000;

    const int status = ioctl(spi_fd_, SPI_IOC_MESSAGE(1), &xfer);

    usleep(50); // FIXME: this  makes sure we don't outrun the co-processor until interrupts are in place for DMA

    if (status < 0)
    {
      logger.error() << "SPI_IOC_MESSAGE: " << strerror(errno);
      return false;
    }

    if (read_buffer[0] != 'J')
    {
      logger.error() << "DMA de-synchronized";
      return false;
    }

    return true;
  }

  int spi_fd_;
  std::mutex mut_;
};

struct WombatDeviceDescriptor
{
  typedef WombatDevice DeviceType;

  static bool isPresent()
  {
    return access(SPI_FILE_SYSTEM, F_OK) == 0;
  }
};

[Zacharyprime]

I don't really see any obvious issues.

Possibly caused by the memset usage?
https://stackoverflow.com/questions/16793612/calling-memset-causes-segmentation-fault

I wouldn't have thought to use memset here so I'm gonna dig a bit more to see if there is a reason.
My understanding is that this is a trick to set all values as 0 but I don't see why that's necessary here.

Definition of spi_ioc_transfer struct:
https://docs.huihoo.com/doxygen/linux/kernel/3.7/spidev_8h_source.html#l00093

Maybe this is caused by delay_usecs or bits_per_word being set to 0?
The cs_change and pad I believe should be set to 0 anyway.

[Zacharyprime]

delay_usecs isn't relevant since we aren't modifying chip select.
The docs don't reference what pad does so I assume it means adding padding zeros to the data, so zero shouldn't matter.
(I saw a few codebases were people were setting this to 0 as well)

I think the bits_per_word being set to 0 might be problematic/
From what I gather the Pi only supports 8 bits anyway.

[bmcdorman]

What line is the segfault happening on? You'll need to compile libwallaby with -g

[bmcdorman]

See discord for a potential fix. Haven't tried it, but that seems likely.