Cannot run example sketches of APM on pixhawk

Hardware Pixhawk family
1

I compiled several example sketches and uploaded them to pixhawk. None of them could run normally.
Then I connected serial 5 to my PC to get console information. It shows that initilization of the hardware works fine, but when the sketch starts, something wrong (seems like register dump) happens.

When the firmware is ArduCopter, console output is like:

Starting ArduPilot /dev/ttyACM0 /dev/ttyS1 /dev/ttyS2
Starting ArduCopter uartA=/dev/ttyACM0 uartC=/dev/ttyS1 uartD=/dev/ttyS2 uartE=/dev/ttyS6
initialised /dev/ttyACM0 OK 4096 1024
initialised /dev/ttyS3 OK 1024 512
initialised /dev/ttyS1 OK 1024 512
initialised /dev/ttyS2 OK 1024 512
initialised /dev/ttyS6 OK 1024 512
ArduPilot started OK
rc.APM finished

When the firmware is an example sketch, console output is like:

Starting ArduPilot /dev/ttyACM0 /dev/ttyS1 /dev/ttyS2
Starting UART_test uartA=/dev/ttyACM0 uartC=/dev/ttyS1 uartD=Assertion failed at file:armv7-m/up_hardfault.c line: 184 task: UART_test
sp: 2000b8d8
IRQ stack:
base: 2000b91c
size: 000002e8
2000b8c0: 0806dce8 000000b8 0806dc22 2000b8d8 2000ed28 08049239 0806dce8 000000b8
2000b8e0: 08042bd1 00000010 20009c24 00000003 00000000 080494c9 080494b5 08053641
2000b900: 00000000 20004c68 20004d14 20005144 00000001 08049439 2000ec04 00000000
sp: 2000ecd8
User stack:
base: 2000ed28
size: 00001ffc
2000ecc0: 00000000 00000000 3ad33333 40a0ab33 00000010 080059a5 08044014 01000000
2000ece0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
2000ed00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 08044033
2000ed20: 00000000 00000000 ffffffff 00000000 00000000 00000000 00000420 80002010
R0: 1000e284 1000cc0c 10004f5c 20020000 20004c68 20004d14 20005144 00000001
R8: 00000000 00000000 00000000 00000000 08025f7d 2000ecd8 080059b3 20020000
xPSR: 20000000 BASEPRI: 00000000 CONTROL: 00000000
EXC_RETURN: ffffffe9

Anyone could help? I’d appreciate any constructive suggestions so much!

Frank

2

looks pretty clear to me… there’s a piece of code at like 184 of the file up_hardfault.c ( no idea what or where that is) that has used something like an assert(…) function call. This assert() call is responsible for aborting the code if there is an unexpected problem… and it seems there is. :slight_smile:

3

Thanks for helping.

I also noticed the Assertion and I traced line 184 of file up_hardfault.c. It calls a function PANIC() which is actually a macro definition of another function up_assert() in up_assert.c, and what up_assert() does is printing the console output:

Assertion failed at file:%s line %d task:%s\n.

So I lost clue… There’s something more in that func, but when I try to trace further I see some assembly code which is beyond my capability…

4

Now I get something funny.

If I

  1. comment a few *.init()(only keep uart and scheduler) in main_loop in HAL_PX4_Class.cpp,
  2. remove the SD card, reboot and get nsh,
    I can manually run some example sketches by typing ArduPilot start.

Sketches like UART_test(in AP_HAL) and simple(in AP_HAL_PX4) work just fine.

----------amended
However, when I try BARO_generic and AP_Compass_test, I get both uartA(usb) and uartF(console) as nsh. That’s probably due to that the last part in rcS failed to call rc.APM(becaue USB is connected). Then I cd to /etc/init.d/ and type sh rc.APM and it starts to work.

Expecting helps from developers!!!

6

This bug has been fixed in master:

Peter

1 Like
7

Good job, thanks!

Fang

8

Hello, I think there are still small issues in the following tests:

AP_HAL/examples/Storage: Initial crash;
AP_HAL/examples/Printf: Grammer error;
AP_Notify/examples/: both do not make the led work;
GCS_Console/examples/Console;
AP_InertialSensor/examples/VibTest;

Besides, ‘LIBRARIES += AP_Scheduler’ should be added to make.inc in the following examples:
AP_Common; AP_BattMonitor; AP_Declination_test; AP_Math/**; AP_Mission; AP_Notify.

Regards.