plusk01 / airdamon_f3 Goto Github PK

When I had the SPI CLK set to 18MHz, the gyro y, z data (so the last 4 bytes of the buff_rx_) seem to be corrupted, likely due to a race condition of being interrupted before we had a chance to read all the data...or something.

I changed the SPI CLK to 36MHz and it works fine, but that seems to indicate a lack of robustness in the EXTI ISR code in the MPU6500 object.

When using DMA-enabled SPI and using the Tx channel ISR (DMA1_Channel3_IRQn), the data that received from the MPU seems to be shifted by 4 bytes.

If I disable the interrupt and instead just wait for the transfer to complete, I get the right result.

// wait for completion
while (DMA_GetFlagStatus(DMA1_FLAG_TC2) == RESET);
transfer_complete_isr();

Thus, it seems to be directly related to the DMA_ITConfig(cfg_->Tx_DMA_Channel, DMA_IT_TC, ENABLE) interrupt.

If the autopilot is being powered by the main power and the VCP USB connection is disconnected, it will not re-initiate the connection after USB is plugged back in.

Currently, if using VCP and trying to write, but no one is consuming the data on the other side, there is a timeout and it can take block, particularly when using printf (which isn't a huge problem as printf is only for debugging). There is also a barely-noticeable delay when using the VCP::write() method.

It seems that it is the fault of the following USB_TIMEOUT code:

void VCP::write(uint8_t* ch, uint8_t len)
{
  if (!usbIsConnected() || !usbIsConfigured()) return;

  uint32_t start = millis();
  while (len > 0)
  {
    uint32_t num_bytes_sent = CDC_Send_DATA(ch, len);
    len -= num_bytes_sent;
    ch += num_bytes_sent;

    if (len == 0 || millis() > (start + USB_TIMEOUT))
      break;
  }
}

It would be better if there was a way to say "If the host USB device is not ready to consume data, don't even try and send." Although I'm not sure if there is an easy way to know that (but I feel like there should be).

Occasionally the tx dma stream gets stuck.

This happens because the transfer error bit is high in the HISR/LISR DMA interrupt status register. The behaviour that is seen is that the tx dma appears to be "stuck" (the processor keeps running fine, but nothing comes out of the uart). Using the debugger, we see that even after setting the stream enable bit, the stream remains disabled. This is because the TE bit is still set (by hardware).

By enabling the TE interrupt and clearing the TE bit when that interrupt is fired, the DMA sends garbage from its buffer (good thing we will use a checksum for comms!) and then the uart tx resumes as expected. See 0b84c5d.

This needs to be done for the f3 chip as well.

For some reason, I had to add

#pragma GCC push_options
#pragma GCC optimize ("O0")
#include <functional>
#pragma GCC pop_options

for SPI/MPU to work with ISR in RELEASE mode.

It seems like the cb_ std::function is the real problem, but it doesn't seem like you can add volatile to a std::function...

when scanning i2c devices, it seems like I have to send some data, even though it seems like the device should expect an ACK after the slave address is sent on the bus...

There seems to be a tight connection with the VCP being initialized and the MPU EXTI.... In beecore/examples/spi_mpu6500/main.cpp note the following comment:

  // for some reason, VCP needs to be initialized for MPU EXTI to work... (in RELEASE)
  VCP vcp;
  vcp.init();

Keep getting gibberish from revo/USART3.

Should be getting t (from stm32-playground).

Not only does airbourne_f4 have an interrupt on USART_IT_RXNE via USARTx_IRQn (like airdamon_f3 does), it has an interrupt on Rx_DMA_IRQn.

What is the benefit of this? This seems redundant? The DMA is already transferring the received data for us behind the scenes. Maybe it is conceivable that since DMA is reading from RDR and clearing the RXNE flag that there may be times when the interrupt isn't able to be fired?

Not sure what is going on, but on the betafpv board, make clean && DEBUG= make flash is corrupting the VCP printf -- nothing prints! (however, as tested on the discovery board with VCP + UART, VCP still reads. Also, note that UART/printf/optimization still prints as expected)

Note that if you add the following to the top of vcp.cpp, the computer will see random characters coming from the VCP:

#pragma GCC push_options
#pragma GCC optimize ("O0")

Also, perhaps change optimization from O3 to O2, see here.