[Scott]

I have a similar problem and I am a rookie.  I am using CC3D with sbus and a x4r sb frsky receiver that is bound to my new Taranis 7xq....I have not changed any settings on the radio, only bound to proceed into vehicle set up.  My ESCs are Emax simon k programable 12 amp.  They will not spin up the motor unless i choose the 50hz rate in the ESC page of the wizard. They will not initialize with the default 490hz or the one shot ESC choices. If I choose 50hz Then the escs power up and calibrate and motors all spin in that section but the configuration will not save to the board.  I've looked all over for the solution.  Any help would be a blessing.

[TheOtherCliff]

I suggest that you set (Output page) all your output min to 1000 and your output max to 1900 and use either PWMSync or PWM@490.

Starting with that, do ESC calibration and Neutral setting as described here:
https://librepilot.atlassian.net/wiki/spaces/LPDOC/pages/12058743/ESC+Calibration

[Scott]

Thanks for the response.  My firmware and BL are up to date and the GCS sees the board.  Following your instructions I went to the outputs tab and found that I could not move any of the sliders.  The settings were 50hzpwm; these could be changes but changing them didn't affect the rest of the page in terms of allowing me to move anything.  I unplugged and replugged the board to reboot.  no change. On the firmware page it shows I have the version 4 bootloader and firmware 16.09.  It identifies the board as copter control.  I cannot manually change and save anything on any tab.  Do remember that running the wizard, i got all the way through to the esc calibration successfully but then after choosing a set of stock settings that matched my 250quad, it would not save.  I had to lower my esc rate to 50hz to get that far and spin up the motors.

It is worth mentioning that there is a yellow flag (error flag) in the firmware information panel in the center of the firmware page.  Hovering over this produces no result.

My input and output show an error state in the flight dat tab.  The error state in output is Servo Output Critical...one of the servos failed to update....the input error is just that my transmitter hasn't been set up.  My receiver is bound, but I havent set up the transmitter yet. 

I've ordered a new F3 board.  If I can't get this worked out, I'll switch and see how that goes...hope you guys can deal with a high maintenance rookie .

[TheOtherCliff]

I recall the orange triangle is just because we didn't mark the 16.09 release with the special mark so it knows it is an official release.  That is documented in the wiki and is not a problem.

FYI: if you unplug the board, go to Firmware page, press Rescue, then plug board in, it will show you Firmware Tag, "git commit hash", and CRC for both the onboard firmware and the firmware bundled with the GCS.  If all these match, then you are already running exactly what the GCS expects.  At that point, press Erase Settings (then OK) and within 25 seconds, it will reconnect and FlightTime will start counting (from about 23) again.  Wait till it gets up to at least say 120 (to make sure the erase is complete) and disconnect the board. (Waiting this long should not be necessary under normal circumstances.)  This should erase the settings and there should be no error messages.

After that, go to Configuration -> Hardware.  Change GPS Speed to 38400 and press Save.  The Save button should turn into a Save button with a green check mark.  Unplug the CC3D and plug it back in.  When it connects in a few seconds (less than 10 for me) you should see that GPS Speed is still 38400.  If it is 38400, you have proven that you can save and remember settings.

After Erase Settings, you might also try simply doing File -> ExportUAVSettings to a temp file, then File -> ImportUAVSettings from that same temp file (and press Save To Board Flash).  Save To Board Flash takes a little less than 1 minute on my setup but you can see it count up during that minute.

[fintremai]

Even my CC3d could not save. I performed the albertferraz procedure:

1 - Download Firmware Cleanflight V 1.10.
2 - Install the drivers indicated for your card
3 - Connect with Cleanflight
4 - At the command line of the CF type "flash_erase"
5 - Return to LibrePilot and do the normal process of installing the firmware
 
To be precise, I used the Cleanflight configurator version 1.10 and showed the Gyro and Accel icons in red. The cc3d has now saved the configuration. Thank you

[Penthane]

I now have 6 'not saving' CC3D's! Four of them brand new! Bought from 2 different suppliers. All of them initially worked. Until I upgraded them to BL4 + LP16.09! Now all 4 of them refuse to save. They're all 'always unarmed', but behave like 'Always armed'. The 2 others have been in airplanes for at least a year, but probably longer, and were working fine, until I upgraded to 16.09. Now they also refuse to save.
One failing? OK, could be hardware. But all 6 of them failing after upgrading to 16.09 must be a BL or FW issue.
I read the Cleanflight-method, but can't get CF to work. Is there any other way to completely wipe a CC3D? And why isn't the 'Erase' option in LP doing the job? Why doesn't LP have a way to REALLY erase the board? Because I'm convinced, after searching the internet about this issue, that it's an LP problem. Something written in (probably) extended mem is causing this problem!

[TheOtherCliff]

There are a few problems with tracking this down.  The big most important ones:

- As far as I know there are no developers that have this problem.

- We don't have a simple set of instructions to recreate the issue starting with a completely erased CC3D.  I suspect that you could take two sets of "exported UAV settings", (defaults.uav and completelyinstalled.uav) and do Import UAV settings alternating one and the other several times over (with NO erases) until all the flash memory blocks were used.  Then it must be erased and maybe the LP erase would fail.  If someone with the problem (that can fix it using CleanFlight) could document how to break it, perhaps like this, then a developer could possibly get it to break and we could understand it.



Other important things that cloud the issue:

- The erase procedure must be followed exactly.  During the erase, the board looks locked up for over 20 seconds and you MUST NOT power it off till the SystemTime counter starts counting again so it might be a user error.

- It sounds like it is a problem that started with 16.09, but there are only a finite number of flash memory blocks.  Changing a setting or two only uses a small number of blocks.  Installing a new version uses a lot, so it would use them up sooner, making it look like the new version is the problem.  Successfully erasing settings makes the blocks all available again.  I think I recall a user that went back to e.g. 15.xx still had the problem which fits with it being a problem with 15.xx all along.

- It's possible that your USB port doesn't produce enough current or your long thin cable doesn't allow enough current.  It might be that adding power from your ESC/BEC after connecting USB,  but  before erasing, (or using a computer instead of a laptop, or a different laptop with better USB power) helps.

- It may be an issue that only happens on one OS and not another.  Most users have Windows OS.  I think firmware developers tend to use Linux; at least I do.

- I would bet that of the users that have this issue, all their CC3D's exhibit the issue.  I recall hearing some say that they had some good ones that later turned out to be "bad".  This implies either - that there is something about that user's setup that causes the issue - or that devs that can't recreate the issue just have never used all the flash blocks up (at least that may be true for me).

- If someone with a broken CC3D (won't erase with LP but will erase with CleanFlight) would be willing to send it to a dev to see if they can successfully erase it with LP, the answer would either be: yes and so the user setup has an issue (possibly not the user's fault, like doesn't work on Windows 10 Vxxxx) or no in which case the dev has a CC3D with the issue and can debug it.

- There are probably other factors that I forgot to mention while writing this.

I read the Cleanflight-method, but can't get CF to work

This sounds important.  Try a different computer and different cable.  CF 1.10 should work.

[Penthane]

As I re-read my own post, I realized my frustration was shining through. That was not my intend.

- As far as I know there are no developers that have this problem.

Maybe devs don't work with chinese copies? Could be a combination of the right (wrong) hardware with 16.09 or specific settings.
Question: What type of craft do ppl with this problem have, heli, drone or fixed wing? I use my CC3D's in airplanes only (I'm a bad pilot). Maybe Devs (almost) never setup for fixed wing?

-If someone with the problem (that can fix it using CleanFlight) could document how to break it, perhaps like this, then a developer could possibly get it to break and we could understand it.

When I get CF running and if CF-Erase works, I'll try to break it again. Can take a while, I'm rebuilding our bathroom, so I'm pretty busy and often too damn tired after.

- The erase procedure must be followed exactly.

 
Done. Doesn't work.

- It sounds like it is a problem that started with 16.09, but  <cut>  I think I recall a user that went back to e.g. 15.xx still had the problem which fits with it being a problem with 15.xx all along.

Last shipment, I had 2 CC3D's that were 'blancs', so there never was a version 15 on them untill after the problem appeared.

I will try out the possible power issues. But all my other CC3D's (10-12pcs) work fine (on 1A USB ports).

I will try Linux. Have a PC running it. Never thought of running LP on it.

- I would bet that of the users that have this issue, all their CC3D's exhibit the issue.

 
Then you would loose that bet, because I have at least a dozen other CC3D's that work fine with either version of LP. The eldest at least for 6-7 yrs. All but one have been up/downgraded before.

- If someone with a broken CC3D would be willing to send it to a dev

Well, if I can't get it to work, it's not much use having it, so in principle I would be willing. Any capable (for this problem) dev in The Netherlands?

Strange thing: My board is recognized as CopterControl, but when fiddling with BL's, it didn't accept the CC-BL. I needed to use the CC3D-version

   

I read the Cleanflight-method, but can't get CF to work
This sounds important.  Try a different computer and different cable.  CF 1.10 should work.

Been there, done that. Using all proven cables and computer setup. It's just me. Tired, can't sleep -> Can't focus.

Thanks for thinking with me/us about this problem!

[TheOtherCliff]

If someone has some CC3Ds that they think are good and some that they think are bad

The aforementioned "import uav settings over and over till all flash blocks are used" is a lengthy procedure because it kind of assumes that the problem is not with the CC3D hardware.  A simpler procedure (that assumes the CC3D is the problem) is:
- erase with CF
- use GCS to verify that it has default values
- make one change with GCS and save it
- reboot the CC3D and use GCS to see if the change is still there (and assuming it is)
- try to erase with GCS and it fails (prove with GCS that the "one change" setting is still "changed")
- try to erase with CF and it works (prove with GCS that the "one change" setting has gone back to default value)

If someone has some CC3Ds that they think are good and some that they think are bad then this test will work differently on the good ones than on the bad ones.  "Try to erase with GCS" will work with good ones and fail with bad ones.  That will prove that the problem is related to a difference in CC3Ds.

At this point, I am guessing that the flash chips in the "bad" CC3Ds (if it is the CC3Ds) need to be "erased longer".  As I recall you hold the chip erase signals active for a certain length of time.  The chips in these "bad" clones might need longer erasing.  The longer time could be the fault of the flash chips being not to spec, the flash chips having a new spec that needs to be coded into LP's erase flash code, or LP code that was not written to spec, but written to "this works".

[TheOtherCliff]

Question: What type of craft do ppl with this problem have, heli, drone or fixed wing? I use my CC3D's in airplanes only (I'm a bad pilot). Maybe Devs (almost) never setup for fixed wing?

I doubt that it is related to the type of vehicle.

Last shipment, I had 2 CC3D's that were 'blancs', so there never was a version 15 on them untill after the problem appeared.

I recall a different user where 15 worked, 16 failed, then 15 failed.

But all my other CC3D's (10-12pcs) work fine (on 1A USB ports).

... I have at least a dozen other CC3D's that work fine with either version of LP. The eldest at least for 6-7 yrs. All but one have been up/downgraded before.

I am guessing these all have 16.09 on them and you use the same PC on all your CC3Ds?

Strange thing: My board is recognized as CopterControl, but when fiddling with BL's, it didn't accept the CC-BL. I needed to use the CC3D-version

My CC3D says CopterControl on the Firmware page.
On Firmware page: Device ID should be 402 and HW Revision should be 2 for CC3D.  It's important to have the correct bootloader.  It is possible to get the wrong one on.  The procedure you use to put a bootloader on when there is none will do it.  This sounds promising enough that I will try putting the wrong bootloader on to see if that makes erase settings fail.

CC vs CC3D:  CC is really old but you did say 6-7 years.  Everything now is CC3D.  You can tell CC vs. CC3D by the chips.

[TheOtherCliff]

- The erase procedure must be followed exactly.

 
Done. Doesn't work.

 
I'm really sorry to ask this.  Really but did you do the "erase settings" from the firmware page and wait a long time while the LED was blinking regularly until finally the FlightTime started counting again?  Usually at about 23 seconds of FlightTime.

I wonder if the LED blinking regularly looks like I am done, when you actually need to wait until the FlightTime counter starts counting.  At that time the LED will be blinking like a normal startup.

[Penthane]

You can ask me anything (related to RC ). I have the same thing with ppl asking me advice with PC's. You try helping them for an hour by phone, finally go over there to find the power plug on the floor. So, I know. Just ask. I do wait 'till stabilized again

I recall a different user where 15 worked, 16 failed, then 15 failed.

Sounds just logical to me.  If you change tyres on your car, one blows out and damages your rims, you can put your old tyres back on, but the rim stays damaged.

I use a PC and two laptops. One laptop is old, barely runs W7 and is for outdoor use. All FC's run 1609, except for one. It's the second plane (a 1.55m Eagle-like) I built and I can't get to the FC without taking the plane apart. Never appeared to me that that was ever going to be be necessary It still runs OpenPilot and not even the last version If it ain't broke......

I've attached a pic of the device info as displayed by GCS. As you can see it's called CopterControl, but everything else fits CC3D.

I finally managed to get BetaFlight running. CF is still refusing cooperation    At least I have 5 revived CC3D's. Number 6 stays in Limbo for now.
So, the CleanFlight/BaseFlight Erase method works for me too.

I had to do two of them twice to get it working and one reverted back to locked state again while it was setting up mixes during the Setup Wizard. After CF/BF-Erasing it again, I ran several test setups and it works OK now.

I've attached a nude pic of one of the devices (without it's casing), so you can see the numbers on the chips.

[TheOtherCliff]

I had to do two of them twice to get it working and one reverted back to locked state again while it was setting up mixes during the Setup Wizard.

That sounds even more like "it needs to be erased longer/more than the spec calls for".  I have wondered if erasing multiple times on LP GCS would eventually really erase it and this makes that sound reasonable.  It may need 10x 100x or more LP erases though, so it's not a test that really needs doing.

If you change tyres on your car, one blows out and damages your rims, you can put your old tyres back on, but the rim stays damaged.

I doubt that LP is damaging the CC3Ds like a blowout damaging a rim on a car (but it's not impossible), especially since good CC3Ds haven't done this over long use in the past.  More likely is that cheap flash chips are out of spec or become out of spec quickly with normal use or that there is another issue like bad power regulator chips or CPU...  What I actually wondered about when I said that is that it was never actually being erased (even with 15.xx) and finally filled up after 15 then 16 and was still full when going back to 15.

So we think you definitely have good and bad CC3Ds (bad is not intended to mean that we know the problem is actually with the CC3Ds, but the word is understandable ).

Would you mind doing this with both a good one and a bad one?
- erase using CF (enough to know it is really erased)
- use GCS to see that it looks like default settings and make one change (I change Hardware page GPS baud rate from 57600 to 38400 for my test) and Save
- unplug/replug USB to power CC3D off/on
- verify that the change you make is still changed
- unplug USB
- go to Firmware page and press Rescue; then plug CC3D USB in
- press Erase Settings and follow the directions
- after erase, unplug/replug USB to power CC3D off/on
- verify that the change you make is erased (good) or still there (bad)

The last line will probably act differently for good versus bad CC3Ds.  This will help to prove that there are good and bad CC3Ds and that a bad one is even bad before the flash blocks are used up.  It will also provide a very simple way to know for sure if any particular CC3D is bad.

[Penthane]

I doubt that LP is damaging the CC3Ds like a blowout damaging a rim on a car

Oh, but we agree on that. I do not mean permanent damage, but more that LP makes some change it can not erase itself. Whether because it's erase time is too short or any other thinkable reason. Changing Version (15/16) doesn't change that. And that's also what bugging me. An erase that doesn't erase .. OK, could be too short, but if I put another FW on, then there shouldn't be anything else on after. But it does! Something's still there, blocking saves. But after CF-erase I can change all settings and erase them with LP without any problem
If you say that CF probably erases longer, then why doesn't LP up it's erase time? It's not like it takes an hour to erase. If it solves the problem ...

Ofcourse I realise cheap parts are very likely to be the actual cause. And I'm under the impression Chinese stuff is getting worse by the day. TP Servo's that used to be pretty reliable, have become unusable lately. It looks like they run the molds for too long, slack everywhere. I've switched to more expensive parts a few times now, because the better parts are getting worse too. I think I'm spending about 20-25% more on electronics than I used to a year ago.

I will run the tests, but can't say when. I'm still very busy rebuilding my bathroom. RC time is limited

[TheOtherCliff]

But after CF-erase I can change all settings and erase them with LP without any problem.

If this is true, it is extremely important and why I asked for the above test:

(the test will) help to prove ... that a bad one is even bad before the flash blocks are used up.

which is not true from what you say, and to me implies that all CC3Ds are "bad"; actually that there is an LP firmware bug such that LP erase will fail after all the flash blocks are used up.

So please try that test with a bad CC3D ... you are saying that LP GCS can erase the one setting, but not once all the flash blocks are used up.  This cause (there is a a problem only after all blocks are used up) is one of the possible causes.

(Programmer Note: flash open fails because all blocks are used up and then it can't even be erased because the open failed?  I haven't been in that code in a while.  I also wonder if they are coming with a modified bootloader that still calls itself version 4.)