Servos at extreme positions during boot!

ok, then it is most likely in the IO firmware.

I wonder if HK have changed the setup on the outputs?
I think if you want to investigate this further you’d need to start putting markers at various points in the IO firmware startup, to see if you can find the point in the IO firmware that is causing these pulses. The markers would be code that pulses a pin on and off a fixed number of times, so looking at a trace you can see when the marker code is run. That allows you to narrow down the cause of the problem pulses.
Note that I don’t see these pulses on an original Pixhawk1. That doesn’t necessarily mean it is a hardware difference, but it is a strong possibility.

Well there seems to be some circuitry missing (or made more simple actually) from the main outputs, which may be why the spikes exist.

Would I need to add the code through the terminal or do I need to edit the IO firmware file and then upload it?

Oscar

there are two approaches. One is to work on the IO firmware then build a new ArduPilot FMU firmware and load it, then that FMU firmware will update the IO firmware via the IO bootloader.
2nd approach is to get yourself setup with a jtag connection directly to the IO processor. You’d need to buy something like a black magic probe, and solder a header onto the io jtag port (I can see in the photo its not populated)

Actially I do have an ST-Link v2, I will order the connector to solder and get back to you.

Oscar

great! I should warn you that jtag to NuttX isn’t in great shape - it is usable, but only with particular versions of gdb and some functions don’t work. Once you have the hw I can give you some tips.

Actually, will be uploading the (edited) official IO firmware through the JTAG or is it possible to edit it in the board, I’m just thinking, if HK has changed the circuitry for the outputs what is the possibility they have made changes to the official IO firmware to get it working with their design and is it even possible to find their custom firmware.

Oscar

nope, ArduPilot gets a CRC of the IO fw on startup, and replaces it if it isn’t correct. It will be running standard IO fw.
They could have a different bootloader, but not a different IO fw. I doubt they have a different bootloader though. More likely they just did something like remove the IO buffers to save a few cents.

Got the connectors the other day and made an adapter board to connect the ST-Link, but one thing I can’t find is actual info about the pinout of the JTAG connector on the Pixhawk, is it the classic 10-pin Cortex pinout, and also does it support SWD mode, cause if not then I’ll have to order an original ST-link or the Black Magic Probe.

Oscar

Tridge (or others): I am experiencing a problem with latest ArduPlane latest beta on a Pixhawk2.1 Cube that I think may relate to what’s being discussed here. If mine is a different problem, I will start a new topic. What I am seeing over the past few weeks is that under certain circumstances of PH reboot, both motors going full RPM until the PH has completed reboot and sends a low throttle signal. I can provide a complete set of photos, videos, flash logs, etc., but was curious if there is any reason during a PH reboot that motor signals should go 100%. Doesn’t make sense to me. Thus far I am just bench testing (without props, thankfully), but am a week or two from installing electronics in the airframe. I don’t have my system in front of me at the moment, but I started ~3 weeks ago with then latest beta ArduPlane, and yesterday upgraded to the latest new beta. When I realized SBus failsafe wasn’t kicking in (when radio turned off), I programmed throttle failsafe, which works fine. If it matters, RC is Dragonlink V3 Advanced 1W Rx, with Tx driven by Futaba 14SG. Cobra motors and Cobra opto ESCs, though Innov8tive (Cobra vendor) and I agree this is likely not an ESC programming issue. Happy to provide lots more detail on the system and sequence, and will start paying closer attention to the sequence of conditions that lead up to racing motors. I haven’t noticed what flight control servos do during that time. Perhaps they are going extreme high too. Fortunately they are not connected to anything at this moment.

Kelly

Still seeing throttles going 100% during a MP-driven reboot of Pixhawk 2.1. Why is that? Fortunately props are off, but leaves me a bit uneasy as I get closer to maiden and props on.

Kelly

Do the ESC’s try to auto detect the protocol on boot? Wondering whether startup “noise” might be confusing the esc’s about pwm vs oneshot/dshot signals etc.
If they are trying to auto detect the protocol, can you try disabling that feature?

The noise you are experiencing might be the same but shouldn’t ESCs always wait for Low throttle signal on startup before they allow anykind of other signal, is it possible you have disabled somekind of startup failsafe on the ESCs?

Oscar

Thank you both for those suggestions. I just received the Cobra programmer for these ESCs, and will dive into the details of their defaults, assumptions, etc.

Kelly

I put an oscilloscope on one of the two throttle channel servo pins on my Pixhawk2.1, then triggered reboot from MP. At rest on the bench before reboot, with the Pixhawk armed and Safe off, scope shows 1100ms on the throttle channel I have connected to scope. When I hit reboot, at first the waveform goes flat briefly (0 volts flatline), then back to 1100ms briefly, then briefly back to flatline, then to 1500ms, which it holds for about 6 seconds (with motors screaming), then back to flatline once reboot has completed. Upon rearm and taking Safe off, 1100ms waveform returns.

Is this expected? At first I thought maybe it was the Dragonlink Rx failsafe settings, but I don’t think it is. I reset throttle channel range to -100 to +100 on 14SG radio, and reset Rx failsafe with throttle left stick held all the way down (-100). No change in behavior upon reboot of Pixhawk from MP.

I can post params file and/or put the video of the oscilloscope (with motors on the audio) on youtube if that would be of interest. I am doubtful this is an ESC programming issue, since the servo ports on the Pixhawk2.1 are clearly putting out a 1500ms signal during the reboot.

FWIW, I have RCMAP_THROTTLE set to 1 (ch1), and the servo functions of ch1 and ch2 set to 73 and 74 (Throttle_Left and Throttle_Right, resp.)

What determines the channel out values during a reboot?

Kelly