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

Fix for Waiting for data (in configurator) problem on F1 targets #1436

Merged
merged 1 commit into from Oct 29, 2015

Conversation

Projects
None yet
7 participants
@ProDrone
Copy link

commented Oct 26, 2015

Solves #1433 (see also cleanflight/cleanflight-configurator#261)

Fixes the Waiting for Data problem in configurator when:

  • Clicking on Save and Reboot button
  • Clicking on Flash Firmware button

When the system reboots after programming the new firmware it still
needs a connect/disconnect cycle to work normal. This cannot be solved
since the bootloader is a fixed program in ROM.

Fix is for F1 targets and only tested on naze boards.

@ledvinap

This comment has been minimized.

Copy link
Contributor

commented Oct 26, 2015

There should be no need to configure pin before reset unless character is transmitted (to charge output capacitance), and code already waits on CLI port.
All pins are Input-floating after reset (JTAG is an exception), state before reset does not change this.

It is good idea to initialize TX pin ASAP after reset, but the pin should be configured in Mode_IPU - this will prevent problems is pin is used for input (initialization may use pin for something different that UART .. at least in future)

@ledvinap

This comment has been minimized.

Copy link
Contributor

commented Oct 26, 2015

BTW: pull-up resistor is clean fix for this ...

@ProDrone

This comment has been minimized.

Copy link
Author

commented Oct 26, 2015

@ledvinap I totally agree. A pull up should have been there, but it isn't. I did put it in Mode_IPU at first, but that wasn't enough to stop the problem from happening. That is why i drive it high. It does not stay there, it is soon taken over by serial port init.

The problem is that the floating line is seen as a break condition. Before, chrome did not react to that, but since a recent update it does (so it is not a normal character transmission). The connection is also corrupted after a break is received, which i a very odd reaction.

It is hard to find a nice place to solder a resistor to +5V on a naze (it must be there when only powered by USB). This PR is intended as a fix for people that do not want to add a pull-up resistor (built in FC's) but just want to have things back to normal 😄

@joshuabardwell

This comment has been minimized.

Copy link
Contributor

commented Oct 26, 2015

A software fix, fixes it for everybody. A hardware fix, fixes it only for people who apply it. Never mind that soldering a pullup to a FC board is beyond many people's abilities.

@ledvinap

This comment has been minimized.

Copy link
Contributor

commented Oct 26, 2015

The mode_IPU not working is strange, the pullup should be enough in ...
Can you check with scope what is happening?

Hmm ... CP2102 input leakage current is 25uA typ, 50uA max ... that is huge, 1V for typical values (40kOhm pullup + 25uA leakage).

So only thing left is if it is really necessary to change output to PP before reset ... ?

@ProDrone

This comment has been minimized.

Copy link
Author

commented Oct 26, 2015

A software fix, fixes it for everybody.

@joshuabardwell
Exactly. That is what i prefered.

@ledvinap
I tried several combinations until i found one that worked.That was after a day or two trying to fix it in the configurator. I did not look with a scope, just used the configurator log, that one reports the break condition. I had the fix with a 10K pull up mounted before doing a software modification.

See also: http://ltxfaq.custhelp.com/app/answers/detail/a_id/736/~/what-is-a-serial-break%3F
I suspect chrome has trouble with a long break.

@ledvinap

This comment has been minimized.

Copy link
Contributor

commented Oct 26, 2015

@ProDrone : So the fix won't work without configuring TX pin as PushPull just before reset?

@ProDrone

This comment has been minimized.

Copy link
Author

commented Oct 26, 2015

@ledvinap
I does work when only applied after reset (i am adapting the code now, can be simpler -hold on).
It was a left over from earlier tests... Thanks for your comments.

@ProDrone ProDrone added this to the 1.10.1 milestone Oct 26, 2015

@ProDrone

This comment has been minimized.

Copy link
Author

commented Oct 26, 2015

@hydra
Ready for merge

@joshuabardwell joshuabardwell referenced this pull request Oct 26, 2015

Closed

Windows10 issue ? #1438

@tracernz

This comment has been minimized.

Copy link
Contributor

commented Oct 26, 2015

Did you try clearing the break condition in configurator? https://developer.chrome.com/apps/serial#method-clearBreak Or just disconnect/reconnect?

@ProDrone

This comment has been minimized.

Copy link
Author

commented Oct 26, 2015

@tracernz That is for controlling the outgoing break on the transmission line. There is no support for an incoming break signal (it even causes a lock up). Connect/disconnect turned out to be not that easy, it had a lot of side effects. Anyway the problem is solved with this PR and all works like it did before.

@Donykurniawan

This comment has been minimized.

Copy link

commented Oct 27, 2015

helo, can you show me step by step to fixs my cleanflight

2015-10-23 @ 14:01:28 -- Running - OS: Windows, Chrome: 46.0.2490.71, Configurator: 0.66.0
2015-10-23 @ 14:02:41 -- Serial port successfully opened with ID: 1
2015-10-23 @ 14:02:41 -- MultiWii API version received - 1.13.0
2015-10-23 @ 14:02:41 -- Flight controller info, identifier: CLFL, version: 1.10.0
2015-10-23 @ 14:02:41 -- Running firmware released on: Oct 2 2015 14:57:31
2015-10-23 @ 14:02:41 -- Board: AFNA, version: 2
2015-10-23 @ 14:02:41 -- Unique device ID received - 0x669ff504853827067210932
2015-10-23 @ 14:03:13 -- EEPROM saved
2015-10-23 @ 14:03:13 -- Device - Rebooting

cant back ready status(hang), i really frustasion about new cleanflight
Thank you

@tracernz

This comment has been minimized.

Copy link
Contributor

commented Oct 27, 2015

@ProDrone I'm not familiar with the Chromium sources but on first inspection it appears the ClearBreak function clears the break condition for the whole connection, not specific to one direction: https://chromium.googlesource.com/chromium/src.git/+/master/device/serial/serial_io_handler_win.cc.

@ledvinap

This comment has been minimized.

Copy link
Contributor

commented Oct 27, 2015

@tracernz : https://msdn.microsoft.com/en-us/library/windows/desktop/aa363179(v=vs.85).aspx, it is sent break only. It does not make sense to clear receive break (other size is responsible).

@ProDrone : Did you try catching onReceiveError ? Maybe .paused is set on break Once this event is raised, the connection may be set to paused. A "timeout" error does not pause the connection.

The PR looks good ...

gpio.mode = Mode_Out_PP;
gpio.speed = Speed_2MHz;
gpio.pin = Pin_9;
gpioInit(GPIOA, &gpio);

This comment has been minimized.

Copy link
@ledvinap

ledvinap Oct 27, 2015

Contributor

Technically you should set PIN state first, then change it to output. There may be very short low-level pulse on output otherwise that may cause problems (it can theoretically generate false startbit, and thus spurious 0xff byte, but most UART implementations have digital filter).

@ProDrone

This comment has been minimized.

Copy link
Author

commented Oct 27, 2015

I'm not familiar with the Chromium sources but on first inspection it appears the ClearBreak function clears the break condition for the whole connection, not specific to one direction: https://chromium.googlesource.com/chromium/src.git/+/master/device/serial/serial_io_handler_win.cc.

@tracernz
I am also not familiar with Chromium sources. I have the intention to keep it that way 😄

Did you try catching onReceiveError ? Maybe .paused is set on break Once this event is raised, the connection may be set to paused. A "timeout" error does not pause the connection.

@ledvinap
I tried that too. Also setting the paused state on purpose then wait and clear that. I had to wait for around 3 seconds before the break was no longer seen. I had to stop all timers and close/reopen the connection. The whole GUI "shaked" upon disconnect/reconnect (because of another set of tabs for online / offline state). At that point i decided to go for suppressing the break instead of consuming it.

I think that from user perspective this PR is a good solution because all works like before.

@ledvinap

This comment has been minimized.

Copy link
Contributor

commented Oct 27, 2015

@ProDrone : Yes, this fix seems reasonable

@ProDrone

This comment has been minimized.

Copy link
Author

commented Oct 27, 2015

Technically you should set PIN state first, then change it to output. There may be very short low-level pulse on output otherwise that may cause problems (it can theoretically generate false startbit, and thus spurious 0xff byte, but most UART implementations have digital filter).

@ledvinap
You mean like so?

    gpio_config_t gpio;

    gpio.mode = Mode_Out_PP;
    gpio.speed = Speed_2MHz;
    gpio.pin = Pin_9;
    digitalHi(GPIOA, gpio.pin);
    gpioInit(GPIOA, &gpio);
@ledvinap

This comment has been minimized.

Copy link
Contributor

commented Oct 27, 2015

Yes, it should work correctly

ProDrone
Working - except when exiting from bootloader
Fixes the `Waiting for Data` problem in configurator when:

- Clicking on `Save and Reboot` button
- Clicking on `Flash Firmware`  button

When the system reboots after programming the new firmware it still
needs a connect/disconnect cycle to work normal. This cannot be solved
since the bootloader is a fixed program in ROM.

Fix is for F1 targets and only tested on naze boards.
@ProDrone

This comment has been minimized.

Copy link
Author

commented Oct 27, 2015

@ledvinap Updated, tested, works the same...

@ProDrone

This comment has been minimized.

Copy link
Author

commented Oct 27, 2015

@borisbstyle Hi Boris, maybe you want to merge this in Betaflight and make people happy 😀

@ledvinap

This comment has been minimized.

Copy link
Contributor

commented Oct 27, 2015

@ProDrone : Yes, the function will be the same. The problem is mostly theoretical, it should not cause any problem with usb-to-uart chips. It may cause problems in other contexts (SPI may detect false clock pulse etc).
It may also cause spurious start when IRQ is serviced between setting pin to output and setting bit in ODR. This may theoretically cause hard to diagnose random bug (not in CF, configurator will simply ignore 0xff byte).

@Donykurniawan

This comment has been minimized.

Copy link

commented Oct 29, 2015

please update in crome when all normal and work. i realy dont understeand about computer language.
gpio_config_t gpio;

gpio.mode = Mode_Out_PP;
gpio.speed = Speed_2MHz;
gpio.pin = Pin_9;
digitalHi(GPIOA, gpio.pin);
gpioInit(GPIOA, &gpio);

@ProDrone I'm not familiar with the Chromium sources but on first inspection it appears the ClearBreak function clears the break condition for the whole connection, not specific to one direction: https://chromium.googlesource.com/chromium/src.git/+/master/device/serial/serial_io_handler_win.cc.

i and all my freands will be happy with new update in crome. Thank you

@ProDrone

This comment has been minimized.

Copy link
Author

commented Oct 29, 2015

@Donykurniawan This is a fix for Cleanflight (not Chrome) code. You have to wait until it is merged in Cleanflight. It will probably be in a new 1.10.1 release.

What version of Cleanflight do you fly with and what is your flightcontroller?

@Donykurniawan

This comment has been minimized.

Copy link

commented Oct 29, 2015

thank you ProDrone, i use,
Running - OS: Windows, Chrome: 46.0.2490.80, Configurator: 0.66.0
2015-10-29 @ 09:05:43 -- Serial port successfully opened with ID: 1
2015-10-29 @ 09:05:43 -- MultiWii API version received - 1.13.0
2015-10-29 @ 09:05:43 -- Flight controller info, identifier: CLFL, version: 1.10.0
2015-10-29 @ 09:05:43 -- Running firmware released on: Oct 2 2015 14:57:31
2015-10-29 @ 09:05:43 -- Board: AFNA, version: 2
2015-10-29 @ 09:05:44 -- Unique device ID received - 0x669ff504853827067210932
2015-10-29 @ 09:06:00 -- EEPROM saved
2015-10-29 @ 09:06:00 -- Device - Rebooting

cant back to ready status, always freezz(hang) in all command

@ProDrone

This comment has been minimized.

Copy link
Author

commented Oct 29, 2015

@Donykurniawan
I build a hex for you, you may get it here: http://www.datafilehost.com/d/afda3391

@hydra

This comment has been minimized.

Copy link
Contributor

commented Oct 29, 2015

Excellent work everyone, merging!

hydra added a commit that referenced this pull request Oct 29, 2015

Merge pull request #1436 from ProDrone/fix_waiting_for_data_problem
Fix for Waiting for data (in configurator) problem on F1 targets

@hydra hydra merged commit 46f6ff4 into cleanflight:master Oct 29, 2015

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

@ProDrone ProDrone deleted the ProDrone:fix_waiting_for_data_problem branch Oct 29, 2015

@Donykurniawan

This comment has been minimized.

Copy link

commented Oct 30, 2015

thank you ProDrone, and everyone. excellent . soon i will try to my naze32 . (:

@Donykurniawan

This comment has been minimized.

Copy link

commented Oct 30, 2015

yesss,,, all work,, with ProDrone Link... Thank you from me and all my friends. excellent work guys

hydra added a commit to cleanflight/cleanflight-configurator that referenced this pull request Dec 16, 2015

Disconnect on F1 boards when 'break' is received if connected. This
happens when the device reboots due to incorrect hardware
initialisation.  This prevents the GUI saying 'waiting for data'.

See cleanflight/cleanflight#1436

Since the problem is already fixed in firmware there's not much reason
to spent development working on additional GUI fixes.  A disconnect will
suffice.
@Lethichore

This comment has been minimized.

Copy link

commented Dec 20, 2015

Hi Guys, I know this is a topic from like 2 months ago but I'm still experiencing this problem, is that normal or should it be fixed by now in the software? I'm running v1.1.0 of the configurator.

I'm using a naze32 acro and as soon as I plug in my battery (with usb already connected to pc) my cleanflight freezes whenever i change tabs and I can't connect to it either without unplugging the battery.

@ProDrone

This comment has been minimized.

Copy link
Author

commented Dec 20, 2015

@Lethichore What you describe is a complete lockup, that is different from the issue soved with this pull request. Do you maybe have some other hardware connected to RX/TX, like a bluetooth module or OSD? TX/RX in the middle of the board, are the same signals as used by the USB connection. So if you power something in parallel at the same time it will not work.

@Lethichore

This comment has been minimized.

Copy link

commented Dec 20, 2015

No I only have my ESC's connected and then the 10pin cable going to my AR610 receiver.
Could this be caused by a bad joint or maybe just a bad board?

@Lethichore

This comment has been minimized.

Copy link

commented Dec 20, 2015

Ok I don't i flashed to firmware 1.9 and now it seems to work just fine... Receiver input is registered too now which didn't work with 1.10 or 1.11, only got to get the motor test working now :)

blckmn pushed a commit to blckmn/cleanflight that referenced this pull request Nov 1, 2016

martinbudden pushed a commit to martinbudden/cleanflight that referenced this pull request Apr 1, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.