PreArm: Internal errors 0x8000 l:404 main_loop_stk after upgrading to latest 4.1.0-dev

ArduRover
1

Hi everybody,

Vehicle type: boat.
Just after upgrading from 4.0.0 to latest 4.1.0-dev this error appeared preventing from arming surely. Most wondering is that this error disappeared after several restarts allowed me to arm the boat. Then it appeared again. Also when the error appears it causes little delay on startup, about 4-5 extra seconds so I know in advance that I’m having it again.
And, if the vehicle starts normally this error doesn’t appear during the travel.

Should I report a bug or somebody have any clues?

The log is here:
https://drive.google.com/drive/folders/1AEP3LLUuWmPUjsavy44UMzehGhnkQY8f?usp=sharing

P.s. The reason for upgrade was the need to read RC input PWM values in Lua script - wasn’t possible in 4.0 scripting bindings.

2

cuase/effect is reversed; everything stopping is what the warning is
telling you what happened…

Can you describe what peripherals you’ve got plugged into this / drivers
enabled?

1 Like
3

The error reproduced without any extra hardware attached (except for M8N). The controller itself is Pixhawk 2.4.8 (Aliexpress), M8N is also from there. Anyway initial flashing and subsequent reboots were with just USB cable attached.

4

@kobaf PreArm: Internal Errors may be relevant here. Rover, and also fmuv3.

I’ll try to reproduce locally.

5

Observed the same error running ArduRover V4.1.0-beta1 (df499ca3).

PreArm: Internal errors 0x8000 l:428 main_loop_stk

Hardware

  • FCU: Matek H743-WING
  • GPS: Matek M8Q-CAN with updated firmware (http://www.mateksys.com/?portfolio=m8q-can#tab-id-8) connected on Serial3 (USART2). Was using serial rather than UAVCAN as the GPS was borrowed from another rover with a damaged CAN port and was wired for a serial connection.

Steps before error

  • FCU on a bench with no GPS fix
  • ESCs connected to SERVO 3 & 4
  • The error occurred after setting SERIAL3_PROTOCOL = 32 (MSP) and GPS_TYPE = 19 from defaults. Force armed to test the ESCs (no reboot after the parameter update).

I have not seen the error after a reboot, so it may have been the param change that put the FCU into a bad state?

6

was this a one off error, or something you can reproduce?

7

@tridge it looks like a one off. I’ve reset the FCU back to defaults and stepped through the same config steps for the GPS and cannot reproduce the error.

The FCU was not properly configured or calibrated - so I doubt I’ll see it again but I understand the internal errors are ‘should never hit this’ type statements so thought it worth reporting in case there’s a pattern.

Update1

Spoke too soon. Not seeing the 0x8000 error reported above but after uploading a Lua script am now seeing a number of different errors (which repeat after a reboot).

  • PreArm: Param storage failed (I changed the SD card for a new one (32GB) - same issue)
  • On force arm:
    • InternalError 0x4000020 then after a reboot and SD card switch
    • InternalError 0x4008020

Suspect FCU flash may be corrupt, so will reflash and start again. I’ll keep this updated, but if there are any steps or tests the dev team would like me to work through I’m happy to do that.

Update2

  • Reflashed ArduRover V4.1.0-beta1 (df499ca3)
  • Enabled scripting and reset params - these changes persist
  • Force arm results in PreArm: Param storage failed which persists after reboot
  • Further parameter changes can be saved from MP and take effect but are lost once the FCU is rebooted

Update3: conclusion