Hi,
Have just set SCR_ENABLE and from that moment can’t connect using USB.
Board is in kind of death loop, all I can hear is a USB like connecting/disconnecting beeps.
Removed card but it helped nothing.
4.6 beta
Any idea? DFU ?
Once again, describe a little more you problem including information which FC
Is it the same you manipulated the firmware for PCM_input and is your firmware running or the unmodified 4.6 beta?
All this information can help to understand your root cause.
I reflashed it starting with bootloader. It is currently operational… Uff.
Originally I kept bootloader it came with… Flashing modified 4.6beta only.
Now it has got bootloader from 4.6 GitHub tree with the same PPM moded firmware.
It appears ok, but I will avoid Lua scripting. 
It seems to me that having an SD card implicitly enables AP_TERRAIN_AVAILABLE
#ifndef AP_TERRAIN_AVAILABLE
// enable terrain only if there's an SD card available:
#define AP_TERRAIN_AVAILABLE HAL_OS_FATFS_IO
#endif
what may not be a case if some modules are not build in:
define AP_RANGEFINDER_ENABLED 0
define AP_OPTICALFLOW_ENABLED 0
define HAL_PROXIMITY_ENABLED 0
define HAL_MOUNT_ENABLED 0
define AP_CAMERA_ENABLED 0
define HAL_GENERATOR_ENABLED 0
define HAL_PARACHUTE_ENABLED 0
define AP_AIRSPEED_ENABLED 0
define AP_AIRSPEED_ANALOG_ENABLED 0
define AP_FENCE_ENABLED 0
define HAL_RALLY_ENABLED 0
define AP_AVOIDANCE_ENABLED 0
define AP_OAPATHPLANNER_ENABLED 0
define HAL_ADSB_ENABLED 0
define MODE_ZIGZAG_ENABLED 0
define MODE_SPORT_ENABLED 0
define MODE_GUIDED_NOGPS_ENABLED 0
define AP_MISSION_NAV_PAYLOAD_PLACE_ENABLED 0
define AP_GRIPPER_ENABLED 0
define HAL_SPRAYER_ENABLED 0
define AP_LANDINGGEAR_ENABLED 0
define AP_WINCH_ENABLED 0
define AP_WINCH_DAIWA_ENABLED 0
define AP_WINCH_PWM_ENABLED 0
List above is what was “disabled” while death loop occurred.
The situation remains unchanged, with the same loop occurring even enabling the modules as default.
Can’t test 4.5.7 as board is to new, so it’a all about 4.6 beta3
Hi @Paul_Paku,
Thanks for helping with beta testing.
Could you make sure that the regular 4.6.0-beta3 or 4.6.0-beta4 is installed on the board and re-test? According to the issue raised it was a non-standard branch. Sorry to create extra work but with the limited resources on the team we can only support the official releases
I spent a few hours, and the results are very strange.
The only FW version is running is a MP downloaded and flashed 4.6 beta4.
Whatever version I build locally has rebooting problem - just after SCR_ENABLEd including fresh new 4.6 beta4 from Github.
The only idea I have is that my build stack differ from official one.
I build on ArchLinux with:
arm-none-eabi-gcc 14.2.0-1
avr-gcc 14.2.0-1
ccache 4.10.2-3
gcc 14.2.1+r753+g1cd744a6828f-1
gcc-libs 14.2.1+r753+g1cd744a6828f-1
gcc13 13.3.1+r432+gfc8bd63119c0-1
gcc13-libs 13.3.1+r432+gfc8bd63119c0-1
and
pyton 3.11.11
1 Like
Hi @Paul_Paku,
Thanks very much for confirming that the standard beta is OK.
The arm-none-eabi-gcc of version 14.2.0-1 looks suspicious.
Our build environment setup instructions are here although I’m sure you’ve already seen them. From a quick look at the install script I think it downloads the correct compiler from here.
Personally I always use the install-prereqs-ubuntu.sh script but there are others for other OSs
FYI @peterbarker @khancyr
1 Like
Yep the arm toolchain is untested version.
Most likely messing up with the LUA compilation but with some hope we can solve this by compiling SITL witht the same gcc version . Otherwise, looking at the warchdog error should give us what is failing
1 Like
I have just installed the recommended versions and will conduct tests shortly.
BTW I initially ran the ArchLinux script version, it did not help.
Let me test new, manual config.
Tested with given arm suite and it’s working.
My bad, again
You may be interested to know that approximately 100kB of flash lost when using the old compiler.
1 Like
The archlinux script is on minimal maintenance as I don’t use archlinux. If you want to update it , we would welcome improvements !
For the toolchain … yep that was expected as we don’t support it yet
The Arch prereqs script worked fine for me a short time ago. I don’t expect there have been significant enough changes to any architecture to change that.
I DO expect that Arch users may be susceptible to these pitfalls due to the propensity for Arch updates to lean toward the bleeding edge. I also expect that anything other than a recent, clean OS install could be problematic for similar reasons.
I also expect that machines used for microprocessor development outside the scope of ArduPilot may be susceptible to version issues in the tool chain.
It might be wise to segregate AP development into a Docker container or dedicated VM.
1 Like
I was just a matter of compiler version.
Just updated to expected version all run smooth.
But yes, Arch is always as fresh as possible. Newest in every piece of code.
Only if poorly/blindly managed.
I posit that most Arch users actually have no business using it because they don’t have the depth of knowledge to manage it well. They get sucked in by the hype.
As in life, it has advantages and disadvantages.
Will look at it, but later.
Beside the toolchain, the other libs are generally easy to fix or use newer version.
For the toolchain, the problem is normally solved because we are providing the toolchain and ask to not use the arm-none-eabi that is given by any distro.
The problem that was seen here isn’t happening solely on arch. Numerous time people are using arm-embedded toolchain on Ubuntu and it breaks the build randomly too … So that is why we provide a fixed version from our server !
BTW we do have docker env and vagrant ready and working !
After building with FIXed version I’m here:
Trying to get log out of board - ArduCopter / Copter 4.6 - ArduPilot Discourse
Disabled Lua, and wondering what would happen if I finally want to go in the air. …
Hence my recommendation