px4fmu-v2 sensor reset

[dagar]

This isn't the ideal solution, but for the majority of cases (good boards and bad) it will bring all sensors back (hard reset and reboot commanded).

Tested on several different pixhawks (3dr, hobbyking, etc).

@svpcom could you try this?

[dagar]

To be clear, there are still situations where we won't get the explicit full sensor reset (eg hardfault), but at this point I believe it's a choice between this PR supporting the majority of boards in most usage, or the more thorough sensor power reset on init that causes an unknown (but seemingly large) number of pixhawks to reset due to a hardware issue.

#8529
#8643
#8703
#8927

[davids5]

@dagar seems like a reasonable alternative. The concern I have is the reduced reliability on V2 compliant HW.

[svpcom]

@LorenzMeier @dagar
Now it always in bad state (even after power on):

INFO  [Unknown] Ver 0xB : Rev 0 V2
[boot] Fault Log info File No 4 Length 3177 flags:0x01 state:1
[boot] Fault Log is Armed
sercon: Registering CDC/ACM serial driver
sercon: Successfully registered the CDC/ACM serial driver
HW arch: PX4FMU_V2
HW type: V2
HW version: 0x0009000B
HW revision: 0x00000000
FW git-hash: 2ce8b6a984184b9fbb53e96b3ce4a11894857eba
FW version: 1.7.3 0 (17236736)
OS: NuttX
OS version: Release 7.22.0 (118882559)
OS git-hash: b18053574bf41712cef93e31bf178518f451a350
Build datetime: Mar  8 2018 16:48:32
Build uri: localhost
Toolchain: GNU GCC, 5.4.1 20160919 (release) [ARM/embedded-5-branch revision 240496]
MFGUID: 353139353134510c00540025
MCU: STM32F42x, rev. 1

WARNING   WARNING   WARNING!
Revision 1 has a silicon errata:
This device can only utilize a maximum of 1MB flash safely!
https://pixhawk.org/help/errata

UID: 540025:3134510C:35313935 
nsh: mount: mount failed: No such device
INFO  [tone_alarm] missing command, try 'start', status, 'stop'
nsh: mkfatfs: mkfatfs failed: No such device
INFO  [tune_control] Publishing standard tune 1
INFO  [param] selected parameter default file /fs/mtd_params
rgbled on I2C bus 2 at 0x55 (bus: 100 KHz, max: 100 KHz)
nsh: rgbled_pwm: command not found
WARN  [dataman] Could not open data manager file /fs/microsd/dataman
ERROR [dataman] dataman start failed
MS5611_SPI on SPI bus 4 at 3 (20000 KHz)
WARN  [ms5611] no device on bus 4
MS5611_SPI on SPI bus 1 at 3 (20000 KHz)
nsh: bst: command not found
WARN  [hmc5883] no device on bus 1 (type: 2)
WARN  [lis3mdl] no device on bus 2
WARN  [hmc5883] no device on bus 2 (type: 1)
WARN  [mpu6000] no device on bus #3 (SPI1)
MPU6000 on SPI bus 1 at 4 (1000 KHz)
INFO  [mpu6000] accel cutoff set to 30.00 Hz
INFO  [mpu6000] gyro cutoff set to 30.00 Hz
WARN  [mpu6000] no device on bus #5 (SPI4)
WARN  [mpu9250] probe failed! 104
WARN  [mpu9250] no device on bus 3
WARN  [mpu9250] probe failed! 255
WARN  [mpu9250] no device on bus 4
ERROR [l3gd20] driver start failed
WARN  [lsm303d] SPI init failed
ERROR [lsm303d] driver start failed
ERROR [param] Parameter SENS_EN_LL40LS not found
ERROR [param] Parameter SENS_EN_LL40LS not found
ERROR [param] Parameter SENS_EN_SF0X not found
ERROR [param] Parameter SENS_EN_SF1XX not found
ERROR [param] Parameter SENS_EN_MB12XX not found
ERROR [param] Parameter SENS_EN_TRANGER not found
ERROR [param] Parameter SENS_EN_TFMINI not found
ERROR [param] Parameter SENS_EN_LEDDAR1 not found
INFO  [load_mon] stack check enabled
ERROR [param] Parameter UAVCAN_ENABLE not found
ERROR [param] Parameter SENS_EN_LL40LS not found
INFO  [px4io] default PWM output device
INFO  [mavlink] mode: Normal, data rate: 1200 B/s on /dev/ttyS1 @ 57600B
ERROR [mavlink] DM_KEY_MISSION_STATE lock failed
ERROR [mavlink] offboard mission init failed (-1)
INFO  [mavlink] mode: Onboard, data rate: 10000 B/s on /dev/ttyS2 @ 1500000B
ERROR [param] Parameter UAVCAN_ENABLE not found
px4flow [203:100]
WARN  [px4flow] scanning I2C buses for device..
INFO  [mavlink] mode: Config, data rate: 800000 B/s on /dev/ttyACM0 @ 57600B
INFO  [init] Mixer: /etc/mixers/quad_x.main.mix on /dev/pwm_output0 
INFO  [init] Mixer: /etc/mixers/vtol_delta.aux.mix on /dev/pwm_output1 
INFO  [tone_alarm] missing command, try 'start', status, 'stop'
INFO  [logger] logger started (mode=all)
INFO  [logger] log root dir created: /fs/microsd/log

NuttShell (NSH)
nsh> 

For me working fix is: d36cd84

[LorenzMeier]

Could you send a PR with the fix? @dagar Do you have the setup to test all?

[svpcom]

@LorenzMeier I've created pull request with this fix a month ago: #8703

[dagar]

@svpcom I don't think that fix is correct. The core problem is what's causing the lsm303d to fail startup. Forcing the version is a workaround.

To summarize, we know what the correct fix is, but it's going to cripple those fmu-v2 units with the incorrect resistor. We're trying to find an acceptable workaround that doesn't brick previously "working" boards.

[svpcom]

@dagar Core problem is that SPI init code doesn't init board with unknown HW version.
In my case 0xB (after reset) doesn't match to 0x8 (HW_VER_FMUV2)
So my fix is to change hw_version to known state.

static void stm32_spi1_initialize(void)
{
        stm32_configgpio(GPIO_SPI1_CS_PC2);
        stm32_configgpio(GPIO_SPI1_CS_PD7);

        stm32_configgpio(GPIO_SPI1_EXTI_DRDY_PD15);

#  if !defined(BOARD_HAS_VERSIONING)
        stm32_configgpio(GPIO_SPI1_EXTI_DRDY_PB0);
        stm32_configgpio(GPIO_SPI1_EXTI_DRDY_PB1);
        stm32_configgpio(GPIO_SPI1_EXTI_DRDY_PB4);
        stm32_configgpio(GPIO_SPI1_CS_PC13);
        stm32_configgpio(GPIO_SPI1_CS_PC15);
#  else

        if (HW_VER_FMUV2 == board_get_hw_version()) {
                stm32_configgpio(GPIO_SPI1_EXTI_DRDY_PB0);
                stm32_configgpio(GPIO_SPI1_EXTI_DRDY_PB1);
                stm32_configgpio(GPIO_SPI1_EXTI_DRDY_PB4);
                stm32_configgpio(GPIO_SPI1_CS_PC13);
                stm32_configgpio(GPIO_SPI1_CS_PC15);

        } else if (HW_VER_FMUV2MINI == board_get_hw_version()) {
                stm32_configgpio(GPIO_SPI1_EXTI_20608_DRDY_PC14);
                stm32_configgpio(GPIO_SPI1_CS_PC15);

        } else if (HW_VER_FMUV3 == board_get_hw_version()) {
                stm32_configgpio(GPIO_SPI1_CS_PC1);
        }

#  endif
}

[dagar]

Ok, that makes sense. The part I want to make sure we get right is the actual version detection. It's a bit convoluted.

[davids5]

The bit in question is PB4. On FMUv2 is is connected to ACCEL_DRDY LSM303D. On the Cube and Mini it is a No connect.

If it is a no connect, we would expect it to read back a 0 when pulled low and a 1 when pulled high.

On the board in question it is driven to a 1. This may be a result of not powering up the sensors cleanly*.

More specifically, the power is not shut off to the sensors (in stm32_boardinitialize the GPIO init is enabling the Sensor Vdd 3.3).

I think it would be fine to add teh 0xB code point as has been done by @svpcom in #8703

*I still think it is not a good idea to not reset the sensors cleanly.

[dagar]

I'll test and merge #8703. I'll do a more exhaustive test of all the fmu-v2/v3 variants early next week when I'm home.

[davids5]

@dagar - Thank you. Once the testing is done please report back.