Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

serial 1wire passthrough for ESCs with the BlHeli bootloader #1159

Closed
wants to merge 3 commits into from

Conversation

nathantsoi
Copy link
Contributor

This pull has been superseded. Please see the new pull request for usage details: #1246

Old:

IO - Program BL Heli flashed ESCs via configurator #216

Allow configuration of ESCs with the BlHeli bootloader via the 1wire (passthrough) interface.

This will NOT work with ESCs that have a bootloader other than BlHeli. E.g. ESCs with the simonk bootloader will not work.

Usage

The user experience is currently not ideal, as you'll need to start the CF configurator, go to the CLI, enter 1wire <esc index> e.g. 1wire 1 to program the first esc. Disconnect, open the BlHeli configurator, pick the USB passthrough tool, click connect, click read, then update the settings. Power off the board and repeat. Still, it sure beats disassembling your quad to re-configure your ESCs.

Note, you'll need a UART/USB adapter on the CC3D.

Full directions are here: https://github.com/nathantsoi/cleanflight/blob/serial1wire/docs/1wire.md#1-wire-passthrough-esc-programming

Note, both updating settings and flashing (updating) BlHeli via this interface is tested and working.

Status

I've tested the following binaries (for the boards I own). If folks could request support for/test other boards, that would be great. Send a schematic if you have one so I can map the GPIO pins, my email is my commits or on my github profile page.

Binaries

NAZE: https://www.dropbox.com/s/1a88bf2jrt68ohe/cleanflight_NAZE-serial1wire-d91cb08c5e495bd892941d7af59443c3.hex?dl=1

CC3D bin (display disabled): https://www.dropbox.com/s/vx4ji4fsuw4e9yl/cleanflight_CC3D-serial1wire-8d3473a99aade980ef0380ff34d24edc.bin?dl=1

TODO

It sounds like @4712 plans to implement integration w/in the BlHeli suite, so all the ESCs could be configured w/in BlHeli suite w/o switching back and forth between the CF configurator. It will also be possible to switch ESCs without rebooting the flight controller.

Ps. to any developers out there, I'd love a code review on this. @samguns?

@borisbstyle
Copy link
Member

This is awesome! It could also be added in configurator as well

@thenickdude
Copy link
Contributor

That's cool! I agree that an MSP implementation and Configurator support would be nice. This would allow the Configurator to automatically disconnect which would save people a step, and provide instructions at the same time.

Is there a reason that ESC_COUNT is 6 and not 8?

@4712
Copy link
Contributor

4712 commented Jul 23, 2015

Blhs will support the whole handling mid of august...

@Zestforlife808
Copy link

This is awesome. Will this work with ESCs that have the SimonK bootloader?

@4712
Copy link
Contributor

4712 commented Jul 23, 2015

No. Unfortunately not.

@nathantsoi
Copy link
Contributor Author

@borisbstyle & @4712, Blhs is awesome, but windows only and not open source (right?) A cross-platform open source implementation in the cleanflight configurator would be ideal. I've playing with the configurator and will hopefully get the chance to add an "ESCs" tab shortly.

@thenickdude, is there an advantage to an MSP implementation vs. putting a nice GUI on top of the CLI command?

Also, my boards only appear to have 6 outputs and it is configured per target. Maybe I missed this, but it seems like we only have a #define for max motors or hardcoded 8 most places. Following the format of timers.c, it seemed to make sense to require the actual number of outputs to be defined per target.

ps. fixed the STM32F3DISCOVERY target

@borisbstyle
Copy link
Member

@nathantsoi I was just saying this is a huge step in the right direction :D.
The gui is using MSP api to communicate with the board.

@lucascheuer
Copy link

@nathantsoi I'm not sure if this is the right spot to post a bug... I've been trying to get this to work because I love the idea, but I've run into a bug (or maybe this is a hardware limitation). I'm using the afromini connected via FTDI to the computer. When I type 1wire 1 in the CLI the serial port immediately fails. It works on the naze I have though.

Any ideas?

@ctzsnooze
Copy link
Contributor

I really look forward to using this but I also can't make it work.

I follow this sequence:

  • Connect USB cable only to the FC
  • Connect to CleanFLight configurator
  • In Cli type 1wire 1 then return (not save or exit though, tried that, makes no difference)
  • Disconnect from configurator
  • Switch to BLHeli 14
  • Under 'Select Atmel/Silabs Interface' I choose blue '1 Atmel BLHeli Bootloader (USB/Com)
  • I confirm that at the bottom I have port set to the same port I connected with CleanFlight
  • I click connect at the bottom of BLHeli...

Then I get the dialog to connect power to read the ESC; if I do connect power, nothing happens.

I think the problem is in BLHeli because the baud rate between the Com Port and the Connect button is 19,200. I cannot connect over USB to the board at 19200 in Configurator. Somehow it must be possible to get BLHeli to talk over USB at 115200? But it is greyed out. I think it will work then.... :-)

But I don't know how to change the BLHeli baud rate for a USB/Com connection.

@thenickdude
Copy link
Contributor

@nathantsoi MSP has error checking and will confirm the success of or retry any failed commands sent to it. The CLI could change appearance in future since it's designed to be used by humans, so it's not good to rely on parsing any of its output.

@nathantsoi
Copy link
Contributor Author

@Elmeerkat, did you add the necessary config for the afromini as described here: https://github.com/nathantsoi/cleanflight/blob/serial1wire/docs/1wire.md#implementing-and-configuring-targets ?

Also, do you see the "Switching to BlHeli mode on motor port x" message before it fails?

@ctzsnooze, what board are you targeting? 1wire 1 immediately disables the cli, and switches to "passthrough" mode so you wont get the opportunity to enter any more commands until you unplug the serial port (or send the the board 0x00 at 110 baud... implementation on the configurator side is coming for this).

The baud rates are a little confusing since the CF configurator speaks at 115200 and the BlHeli bootloader is fixed at 19200. This is actually ok though because as soon as the 1wire command is entered, "passthrough mode" sends all traffic from the UART/USB converter to the esc specified. The flight control board is now is baud-agnostic it is basically just "wiring" passing through the serial traffic, so we disconnect the configurator and connect with BlHeli Suite at 19200 to talk to the esc.

Here's a short guide for the CC3D: https://www.youtube.com/watch?v=fmUPL1lRcss I'll post a video for the naze shortly, if that would be helpful.

Also note, I had the same problem in development, with my debugging harness attached. The leads through my logic analyzer were quite long and my guess is that the extra resistance was causing slow enough rise times that BlHeli couldn't connect. It may be the case that your setup has a similar problem. It might help to fully power your board from the start (ie. plug in the battery).

Final note, I've been testing with the latest BlHeli firmware, v14. Are you perhaps running an older firmware? On what ESC? I can test out the latest v13.x and see what happens.

@thenickdude, excellent point. I'll look at the MSP interface.

@4712
Copy link
Contributor

4712 commented Jul 26, 2015

@nathansoi: "baud-agnostic" does not hit the point. It is the driver for the usb-uart device that sets the baud rate to real 19200 when open the port with BLHeliSuite and again to 115200 if you reopen it with the configurator.

@nathantsoi
Copy link
Contributor Author

Good point @4712, I've updated my comment, I hope it's a bit more clear now...

@ctzsnooze
Copy link
Contributor

It's strange that it's not working for me. I have now tried a lot of times with no success. I am on a Mac and initially was using CleanFlight in the Mac environment and BLHeli on VMwareFusion. Now I put both in VMWare fusion still the same issue. I'll make a movie.

@lucascheuer
Copy link

@nathantsoi I just compiled for Naze. I was under the impression that the afromini uses the same firmware as the Naze. And no, I did not see the switching mode. It just immediately disconnected from configurator and said serial port failure every time I tried

@ctzsnooze
Copy link
Contributor

I get identical findings with AfroMini and standard Naze32, FTDI for the AfroMini and USB/Silabs for Naze32.

@RCMaca
Copy link

RCMaca commented Jul 27, 2015

It works with Flip32 w/ Xrotor10A (Silabs) perfectly - very easy and fairly slick actually
It doesn't work with Mullet32 w/ Xrotor20A (Silabs) at all.

@ksal0
Copy link

ksal0 commented Jul 27, 2015

I'm having the same issue as ctzsnooze with MAC and VMWARE.
When I try to connect with BLHeli my NAZE reboots instead of connecting to the ESC.
Gonna try it on a native windows box later.

@nathantsoi
Copy link
Contributor Author

You might try powering you copter with a battery @ksal0? Ps. I have been testing mac + vmware and when it works, it works fine with this setup :)

@nathantsoi
Copy link
Contributor Author

If a certain setup won't connect, ie. BlHeli just hangs on the waiting for esc screen:

screen shot 2015-07-27 at 8 08 43 am

It might be worth trying to add an external pull-up resistor like so:

screen shot 2015-07-27 at 8 01 35 am

This would help identify if the issue is hardware or software related.

@Trussroads
Copy link

I am now building a PC for this and many other programming issues that arise when trying to work on electronics using a Mac with VMware or other windows host.. It's not the host actually but the way the Mac/OSX handles the USB ports.. It got weird from 10.7 onwards (google it) I've had occasional success but I've never been able to solve it completely.. It just becomes too painful to mess with every time you plug in to something and so I think the only sensible way to do PC based software uploads with a Mac is DONT! Just buy any old crapper PC and gain the extra years to your life is my suggestion :D

On 28 Jul 2015, at 12:13 am, ksal0 notifications@github.com wrote:

I'm having the same issue as ctzsnooze with MAC and VMWARE.
When I try to connect with BLHeli my NAZE reboots instead of connecting to the ESC.
Gonna try it on a native windows box later.


Reply to this email directly or view it on GitHub.

@ctzsnooze
Copy link
Contributor

So far I've had no particular issues at all with serial devices under VMWare.

I'll try the resistor later. Definitely 3.3V as the source?? I'm using sn20a's with all soldered wires, not so easy to add the resistor.

@jaapp
Copy link

jaapp commented Jul 28, 2015

It doesn't seem to work for me as well (naze32, afro12a esc's). When I try to connect BLHeli 14 to the esc, the esc seems to go into a boot loop. As I hear the three initialisation beeps (due to a 3s lipo) over and over again in rapid succesion and the BLHS never connects.

@borisbstyle
Copy link
Member

Are you using blheli bootloader om afro escs?
Op 28 jul. 2015 18:22 schreef "jaapp" notifications@github.com:

It doesn't seem to work for me as well (naze32, afro12a esc's). When I try
to connect BLHeli 14 to the esc, the esc seems to go into a boot loop. As I
hear the three initialisation beeps (due to a 3s lipo) over and over again
in rapid succesion and the BLHS never connects.


Reply to this email directly or view it on GitHub
#1159 (comment)
.

@jdn-za
Copy link

jdn-za commented Jul 28, 2015

Much excite!

@jaapp
Copy link

jaapp commented Jul 28, 2015

@borisbstyle That will be the problem. I assumed that flashing BLHeli changed the bootloader as well, but I understand now that I've been flashing BLHeli using the SimonK bootloader (since that was installed on the afro's by default).

@ctzsnooze
Copy link
Contributor

Duuuuuhhhhh!!! OK that's my problem too, I have the original SimonK boot loader... !!!! Get back to you later. That detail needs to be in big print... :-)

@nathantsoi
Copy link
Contributor Author

@joshuabardwell, do you have an arduino sitting around? You could make an Arduino BLHeli Bootloader interface to test with:

screen shot 2015-09-02 at 9 46 13 pm

@joshuabardwell
Copy link
Contributor

I've no problem flashing that way. I'm just trying to help development by reporting that it's not working for me. And it'd be nice to be able to flash my ESCs without taking the top plate off my copter to get at the motor leads.

@nathantsoi
Copy link
Contributor Author

ok, if you can flash with an arduino and interface 1 or C selected, then you def. have the blheli bootloader

screen shot 2015-09-02 at 10 38 49 pm

i appreciate the help testing, totally feel the 'not tearing apart the copter to change my escs'... that was the original motivation to make this work :)

@joshuabardwell
Copy link
Contributor

I don't use either of those because I'm always working over the signal wire if I can possibly help it. I use number 2. I think this may cause some ambiguity, since the 4w-if interface can handle both bootloaders, but I used to use the 1-wire interface with BLHeli selected, before 4w-if was invented. So I'm really 99% sure these have BLHeli bootloader on them. But not 100%, I guess.

@nathantsoi
Copy link
Contributor Author

I actually was using the single wire interface as well, but via Interface 1: http://nathan.vertile.com/blog/2015/06/17/updating-blheli-via-1-wire/ (the guide says to make a 4w programmer, but before those existed, i was using a blheli bootloader interface via 1wire), if you want to test it out at some point or maybe try it on a different (less assembled) quad?

@4712
Copy link
Contributor

4712 commented Sep 3, 2015

Check:
Try to use CLI to set 1wire mode and then select interface 1 for connection.
Or use interface 6 and click connect. Cycle power of the ESC and click Read Setup...

@joshuabardwell
Copy link
Contributor

I tried 1wire 1 with USB/Com interface last night and no dice.

@4712
Copy link
Contributor

4712 commented Sep 3, 2015

Really BLHeli bootloader not SimonK?
Please check out which bootloader revision is used. See the log.... BootMsg "471c"?

@borisbstyle
Copy link
Member

I think either some old bootloader or simonk.
I literally reflashed 20 different escs yesterday and all fine.
Op 3 sep. 2015 17:38 schreef "4712" notifications@github.com:

Really BLHeli bootloader not SimonK?
Please check out which bootloader revision is used. See the log....
BootMsg "471c"?


Reply to this email directly or view it on GitHub
#1159 (comment)
.

@joshuabardwell
Copy link
Contributor

Really BLHeli bootloader not SimonK?

I don't know how I could have flashed previously via 1wire if I was selecting the wrong bootloader type. Could that even work?

Please check out which bootloader revision is used. See the log.... BootMsg "471c"?

Can you give more detail about where to find the log?

@joshuabardwell
Copy link
Contributor

Ok guys, I think you can go ahead and ignore this one. I flashed the Uno with the Arduino BLHeli Bootloader programmer and selected interface 1, and got the exact same results. Although I am darn sure that I have flashed these using 1wire and BLHeli bootloader, the most likely explanation at this time is that my ESCs have SimonK bootloader. Regardless, I get the exact same results with the serial passthrough as I do via an Uno-based programmer, so your code is not at fault.

Thanks much for the effort.

@joshuabardwell
Copy link
Contributor

BTW, if the log of the 4w-if reads, "cmd_InterfaceSetMode OK AtmelSK" does that mean I have SK bootloader?

@4712
Copy link
Contributor

4712 commented Sep 4, 2015

@joshuabardwell:
Yes, but iIt's even more simple: The current selected mode (Bootloader) is shown in the window title.
blhelisuitesetup_04 09 2015_1

BTW the version of the BLHeli Bootloader is found here:
blhelisetuplogwindow_04 09 2015_1
It is not shown for the Simonk bootloader.

@joshuabardwell
Copy link
Contributor

Well, how about that. I'm really amazed an ESC ordered factory pre-flashed with BLHeli would have SK bootloader. And I have no idea how 1wire ever worked before. But there you go...

@add1ct3dd
Copy link
Contributor

It's a lot more common than you think.

Are they DYS bl20a's by any chance?

Anyway, back on topic!! :P My email is being filled with support requests rather than pull requests 💃

@JohnOCFII
Copy link

I think 1-wire is known to work with either boatloader (part of its appeal).

http://blog.oscarliang.net/esc-1-wire-bootloader-signal-cable-blheli-simonk/

@joshuabardwell
Copy link
Contributor

I didn't realize that. I thought that 4w-if was the first to be bootloader-agnostic. Odd that there is a separate menu option for the different bootloaders, though, if it doesn't matter.

@add1ct3dd They are F-12A ESCs from RTFQ. I just don't get it ... if the vendor is flashing them anyway, why not flash with the "right" bootloader?!?! Grr.

@4712
Copy link
Contributor

4712 commented Sep 4, 2015

The cleanflight solution, we are talking about here, does not support SimonK bootloader.

@add1ct3dd
Copy link
Contributor

Yup, detailed in first post.

@joshuabardwell
Copy link
Contributor

I know that. What I didn't know was that the old 1-wire solution (using Arduino Uno programmer) was bootloader agnostic. Because I had previously flashed using 1-wire (BLHeli), I believed that meant that I had BLHeli bootloader.

@sim-
Copy link

sim- commented Sep 22, 2015

Hey all! You could just have asked, and I could write a host-side serial bridge to the Turnigy USB linker style encoding, but it turns out sambas already did it: sambas@c4af093

You can also see a "bit dump" ;) of a linker-to-UART thing I did to test on stm32f4discovery here: http://0x.ca/sim/tmp/stm32f4-wavegen.zip

As you can see, not that complicated if it's just doing serial pass-through and the host is actually doing the rest. The reason I went with this implementation originally is that it's not possible to arm and smack you in the face no matter what you send to the serial port, even with "oneshot125" enabled. I figured this was more important than maintaining compatibility with the serial linkers, but serial to a UART is probably going to be less code. Also, stk500v2 because the avrdude author recommended it rather than inventing something new (also a bit more code). It's nopped out a bunch, too, and has a page duplicated for self-updating, but I might be able to squeeze in 256 bytes if that would be helpful.

Let me know if this would help -- I can also work with sambas. Note that wherever this boot loader is, it can also keep up with down to 5µs quarter-bit timing (115200bps) if the flight board side can also keep up.

@4712
Copy link
Contributor

4712 commented Sep 22, 2015

@sim- unfortunately I cannot compile the samba code for my NAZE without further changes.
But compiling it for COLIBRI results in increased size of 3224 bytes.
Whereas the so called 1wire mode for AVRootloader (BLHeli bootloader) consumes only 488 bytes (MSP only - without CLI integration, or 936 bytes including CLI integration).
But why not, I know, a lot users are keen to use the stk500v2 bootloader, because it is already widely spread.
But what sense would it make to squeeze the STK500v2?
Why not simply use the readily available BLheli bootloader for SimonK firmware?
https://github.com/4712/BLHeliSuite/tree/master/BLHeli_HexFiles/Bootloader/Atmel/AVRootloader%20Source%20for%20BLHeliSuite

EDIT: 256 bytes would be more a dream ... ;)

@sim-
Copy link

sim- commented Sep 22, 2015

Well, that sounds broken, and obviously shouldn't be merged like that. The diff should affect only the soft serial encoding part, and should be tiny. But do you mean CLI integration within the FC console? If so, sure, that would mean merging stk500v2 communication there, too, as opposed to just pass-through to some other application.

Again, I explained the reason above: with a standard UART connected to ESC input, it's possible for any other application to accidentally open the port and send commands that may look like valid PWM pulses. I haven't seen this happen yet, and it probably doesn't matter if implemented by the FC (where the host would have to enable pass-through mode first or otherwise be limited to what is on the FC), so it probably doesn't matter there.

Probably we/you should ship a temporary boot loader in application space so it can load a new boot loader (switch to AVRootloader or otherwise) without having to break out another interface first for whatever ESCs happen to be present. I guess it can't change the boot loader size fuses, though. :(

@4712
Copy link
Contributor

4712 commented Sep 22, 2015

The CLI integration is - in my opinion - obsolete. It insures, that the user can switch the pass through manually. Well - for testing purposes it might be useful.

Yes the fuses are a special theme, but writing this, better don't ask about the factory fuse settings :(
Wrong bootloader size and BOOTRST disabled (well i know there are pros and cons).
As BLHeli has learned to check for both bootloaders, I could check if there is a chance to exchange the bootloaders for BLHeli, but SimonK does not check the new bootstart?
If the bootloader area is write protected, this would fail anyway.

@sim-
Copy link

sim- commented Sep 23, 2015

Hmm, so, if my ESC code is present, the default setting is just to check for not 0xffff and not 0x0000 at BOOT_START, which defaults to THIRDBOOTSTART. I guess this actively defeats your boot loader, since there would be 0xffff there, since it doesn't start until later. But if it just jumped to it anyway, it would nop-sled to your boot loader, and work. Hmm.

Maybe if I add code to check each of the boot loader starts and jump to the first non-empty one, that would help this situation. Likewise, maybe you could add an .org in (the middle of) your code to trampoline from THIRDBOOTSTART to FourthBootStart, even if your code is too large to fit otherwise. This would be kind of ugly, though. The alternative would be to just never use the boot loader fuses and do it all from the application. I originally avoided this so it could recover from an incomplete flash, but I found another way to do this as well: the program starts by jumping to the end which jumps to the real start. This way, if the flash is incomplete, it nop-sleds back into the boot loader. Not fool-proof, but better than half of a program that can't do anything.

Anyway, I will check the code and maybe propose a better patch or something.

@4712
Copy link
Contributor

4712 commented Sep 23, 2015

Actually BLHeli checks for the first 3 bytes to detect any of both bootloaders (see https://github.com/bitdump/BLHeli/blob/master/Atmel/BLHeli.asm#L5399). And it is also working for Atmega168.
It is not guaranteed that the flash is erased completely, while the latter BLHeliSuite revisions take care of a complete erase.

@edgarasm
Copy link

edgarasm commented Oct 7, 2015

The multi-ESC passthrough does not work with newest betaflight_SPRACINGF3.hex, only first ESC is read, however it works with newest betaflight_NAZE.hex just fine. I recall it working with previous hex, but not sure which one, could the problem be the new blhelisuite 14.1.0.3?

martinbudden pushed a commit to martinbudden/cleanflight that referenced this pull request Sep 14, 2016
nathantsoi added a commit to nathantsoi/betaflight that referenced this pull request Oct 2, 2016
martinbudden pushed a commit to martinbudden/cleanflight that referenced this pull request Jan 25, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet