No RC input px4fmu-v4pro_default

[sanderux]

On my pixhawk 3 pro i loaded todays master and noticed i wasnt able to calibrate radio as no input was detected. The radio works fine and is bound to the transmitter

@LorenzMeier who is on this?

[dagar]

Do you recall the last time/px4 version this was working?

[sanderux]

No, finaly got to soldering telemetry cables so this is my first attempt

[sanderux]

@klopezal ping

[sanderux]

same on beta branch

[klopezal]

Are you using SBUS or PPM?

[sanderux]

SBUS
FRSKY X8R, correctly connected, working on dropix

[klopezal]

That board (V1.2) uses SBUS_INV from FMU (https://github.com/PX4/Firmware/blob/master/src/drivers/boards/px4fmu-v4pro/board_config.h#L299) to invert RC signal (XOR gate) for SBUS (the inverted signal then goes to IO processor). We have to check that the inversion is correct.

Is PX4IO loaded and working correctly?

[sanderux]

Is PX4IO loaded and working correctly?

I dont know, i dont have much connected to it, only telemetry and rc
Is it working on master on your end?

[klopezal]

What is the output of px4io status in console? I'll be back tomorrow morning to test.

[sanderux]

NuttShell (NSH)
nsh> 
nsh> px4io status
WARN  [px4io] loaded
protocol 4 hardware 2 bootloader 3 buffer 64B crc 0x1d6a0279
8 controls 8 actuators 18 R/C inputs 2 analog inputs 0 relays
616 bytes free
status 0x1e00 SAFETY_OFF RC_FAIL FMU_FAIL MIXER_FAIL ARM_SYNC INIT_OK FAILSAFE
alarms 0x0030 FMU_LOST RC_LOST
vservo 418 mV vservo scale 10000
vrssi 1187
actuators -25000 -25000 -25000 -25000 -25000 -25000 -25000 -25000
servos 0 0 0 0 0 0 0 0
reversed outputs: [________] trims: r:   0.0000 p:   0.0000 y:   0.0000
0 raw R/C inputs
R/C flags: 0x0000
mapped R/C inputs 0x0000
ADC inputs 172 1734
features 0x0008 RSSI_ADC
arming 0x0410 FMU_DISARMED IO_ARM_DENIED INAIR_RESTART_OK OVERRIDE_IMMEDIATE
debuglevel 0
controls 0: 0 0 0 0 0 0 0 0
controls 1: 0 0 0 0 0 0 0 0
controls 2: 0 0 0 0 0 0 0 0
controls 3: 0 0 0 0 0 0 0 0
input 0 min 1000 center 1500 max 2000 deadzone 10 assigned 255 options 0x0000
input 1 min 1000 center 1500 max 2000 deadzone 10 assigned 255 options 0x0000
input 2 min 1000 center 1500 max 2000 deadzone 10 assigned 255 options 0x0000
input 3 min 1000 center 1500 max 2000 deadzone 10 assigned 255 options 0x0000
input 4 min 1000 center 1500 max 2000 deadzone 10 assigned 255 options 0x0000
input 5 min 1000 center 1500 max 2000 deadzone 10 assigned 255 options 0x0000
input 6 min 1000 center 1500 max 2000 deadzone 10 assigned 255 options 0x0000
input 7 min 1000 center 1500 max 2000 deadzone 10 assigned 255 options 0x0000
input 8 min 1000 center 1500 max 2000 deadzone 0 assigned 255 options 0x0000
input 9 min 1000 center 1500 max 2000 deadzone 0 assigned 255 options 0x0000
input 10 min 1000 center 1500 max 2000 deadzone 0 assigned 255 options 0x0000
input 11 min 1000 center 1500 max 2000 deadzone 0 assigned 255 options 0x0000
input 12 min 1000 center 1500 max 2000 deadzone 0 assigned 255 options 0x0000
input 13 min 1000 center 1500 max 2000 deadzone 0 assigned 255 options 0x0000
input 14 min 1000 center 1500 max 2000 deadzone 0 assigned 255 options 0x0000
input 15 min 1000 center 1500 max 2000 deadzone 0 assigned 255 options 0x0000
input 16 min 1000 center 1500 max 2000 deadzone 0 assigned 255 options 0x0000
input 17 min 1000 center 1500 max 2000 deadzone 0 assigned 255 options 0x0000
failsafe 0 0 0 0 0 0 0 0
disarmed values 0 0 0 0 0 0 0 0

[LorenzMeier]

If you flash latest master does it still behave the same?

[klopezal]

Yes it does, bug was introduced by PR 6678 (Oneshot mode) and only affects FMUv4pro. Currently looking for it.

[klopezal]

@LorenzMeier @sanderux @davids5
Solved by PR #7167.

It looks like it was a memory issue. However some elements remain obscure to me, shouldn't px4io-v2 binaries be of exactly the same size for FMUv2 and FMUv4pro?

FMUv2 (master) :
[PX4IO] programming 55180 bytes...

FMUv4pro (master) :
[PX4IO] programming 58616 bytes...

[davids5]

@klopezal - Thanks for testing latest.

Yes it does seem odd

diffing the symbols from
arm-none-eabi-nm -n -S -C /<build/>/src/modules/px4iofirmware/px4io-v2

I removed the addresses and left just the size

...

So things are different but why is the question.

[dagar]

Save and compare the verbose output from both builds. Is the px4iofirmware module building with different options?

[davids5]

@dagar, @klopezal @LorenzMeier @sanderux

Ok I have figured it out why the size is different.

When libuavcan is built it looks at CMAKE_BUILD_TYPE and sees it not set so it defines it.

This causes -O2 -g -DNDEBUG to be added to the build vars.

This is what libuavcan does:

*CMAKE_BUILD_TYPE :  : Build type.
!CMAKE_BUILD_TYPE        : RelWithDebInfo : Build type.
*CMAKE_CXX_FLAGS  : -g -fno-exceptions -fno-rtti -std=gnu++11 -fno-threadsafe-statics -DCONFIG_WCHAR_BUILTIN -D__CUSTOM_FILE_IO__ -fcheck-new -Wall -Werror -Wextra -Wno-sign-compare -Wshadow -Wfloat-equal -Wpointer-arith -Wmissing-declarations -Wno-unused-parameter -Werror=format-security -Werror=array-bounds -Wfatal-errors -Werror=unused-variable -Werror=reorder -Werror=uninitialized -Werror=init-self -Werror=unused-but-set-variable -Wformat=1 -Wdouble-promotion -Werror=double-promotion -Wno-missing-field-initializers -fvisibility=hidden -include visibility.h -mcpu=cortex-m4 -mthumb -march=armv7e-m -mfpu=fpv4-sp-d16 -mfloat-abi=hard -nodefaultlibs -nostdlib -Os -fno-strict-aliasing -fomit-frame-pointer -funsafe-math-optimizations -ffunction-sections -fdata-sections -fno-strength-reduce -fno-builtin-printf : C++ flags.
*CMAKE_C_FLAGS    : -g -std=gnu99 -fno-common -Wall -Werror -Wextra -Wno-sign-compare -Wshadow -Wfloat-equal -Wpointer-arith -Wmissing-declarations -Wno-unused-parameter -Werror=format-security -Werror=array-bounds -Wfatal-errors -Werror=unused-variable -Werror=reorder -Werror=uninitialized -Werror=init-self -Werror=unused-but-set-variable -Wformat=1 -Wdouble-promotion -Werror=double-promotion -Wbad-function-cast -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -fvisibility=hidden -include visibility.h -mcpu=cortex-m4 -mthumb -march=armv7e-m -mfpu=fpv4-sp-d16 -mfloat-abi=hard -nodefaultlibs -nostdlib -Os -fno-strict-aliasing -fomit-frame-pointer -funsafe-math-optimizations -ffunction-sections -fdata-sections -fno-strength-reduce -fno-builtin-printf : C flags.
*UAVCAN_USE_CPP03 : ON : Use C++03 standard.
*UAVCAN_PLATFORM  : stm32 : Platform.
*CONTINUOUS_INTEGRATION_BUILD     : OFF : Disable error redirection and timing tests
*UAVCAN_CMAKE_VERBOSE     : OFF : Verbose CMake configure output
 (*)# if a default has not already been defined, use default from table
 (!)# option has not been set already or it is empty, set it with the default

V2:
-rwxrwxr-x. 1 david_s5 david_s5 55640 May 17 16:31 build_px4fmu-v2_default/tmp/ROMFS/px4fmu_common/extras/px4io-v2.bin

V4: Not Allowing UAVCAN to set RelWithDebInfo V4 px4io build is the same size as V2
-rwxrwxr-x. 1 david_s5 david_s5 55640 May 17 16:10 build_px4fmu-v4pro_default/tmp/ROMFS/px4fmu_common/extras/px4io-v2.bin

V4: Allowing UAVCAN to set RelWithDebInfo
-rwxrwxr-x. 1 david_s5 david_s5 59052 May 17 16:28 build_px4fmu-v4pro_default/tmp/ROMFS/px4fmu_common/extras/px4io-v2.bin

@dagar I do not think we want a lib to change the build type. So we should set it. Possibly based on a env var so we as dev can override it it if need be.

[dagar]

It's the standard cmake way for switching between debug and release. We probably should have been using it properly from the beginning and any cmake subprojects will then inherit.

[LorenzMeier]

Closing as stale.