[Penthane]

And then number 6 worked too! They all work now. I was trying some things I thought of (hadn't read your msg yet).
- I flashed BF1041-fw on the last bad CC3D from GCS then replugged.
- Erased from BF's CLI using 'Flash_Erase' command and replugged.
- Went back to LP1609 and used U&E to reflash LP1609 and replugged.
- Changed attitude roll to 180, saved and got a green tick (for the first time with this one), then replugged.
- Attitude roll was still 180 and unplugged.

After I read your msg, I ran your grocery list on all of them.

I've done the tests:
V- 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
V- unplug/replug USB to power CC3D off/on
V- verify that the change you make is still changed
V- unplug USB
V- go to Firmware page and press Rescue; then plug CC3D USB in
V- press Erase Settings and follow the directions
V- after erase, unplug/replug USB to power CC3D off/on
V- verify that the change you make is erased (good) or still there (bad)

They all passed! They work flawlessly now.

I wonder, I presumed the CC3D was a blanc when I got it, because it didn't boot. But could there have been some (remains of) corrupted fw on? Something that didn't boot, but did interfere with LP? Does a CC3D have something like 'restricted/protected area' in memory? Or some mem location LP doesn't use and might be written by another fw, whether intended or not (corrupt). But still, LP should erase completely. I still think CF/BF does erase some memory location LP doesn't, because after U&E the initially 'blanc' CC3D, everything works. You can run the wizard and the servo's will move, motor will run ... untill you get to wizard setting up mixes. Then it hangs. If you manually change things, it's the same, but you can't save anything. You get a red cross every time.  All would support your idea of the longer/deeper erase. But what's nagging me is that -IMHO- if caused by a low spec/faulty mem chip, I'd expect random errors. It wouldn't work in exactly the same way on every 'faulty' CC3D, would it?

[TheOtherCliff]

So now, even your "bad" CC3Ds work correctly ... and LP EraseSettings does erase?

Maybe there is only a problem if the CC3D flash chip is allowed to become completely full so that it can't save more settings?  This may imply that all CC3Ds are "bad" (it would probably actually mean there is an LP bug in this use case).

Maybe you are doing something differently than before?    Maybe Rescue Erase works where the way you used to erase doesn't?

Did you flash the bootloader and that made them work?

Maybe some clone flash chips get better after a few erases.

Does a CC3D have something like 'restricted/protected area' in memory? Or some mem location LP doesn't use and might be written by another fw, whether intended or not (corrupt). But still, LP should erase completely.

There are several kinds of memory on the CC3D.  This kind of memory is like a thumb drive and doesn't have "protected areas".

I still think CF/BF does erase some memory location LP doesn't, because after U&E the initially 'blanc' CC3D, everything works. You can run the wizard and the servo's will move, motor will run ... untill you get to wizard setting up mixes. Then it hangs.

This is best explained by that initial LP erase not erasing (maybe did you U instead of U&E?), and like a used computer drive that you didn't format, it is already partly full and so the program installation fails part way through.  Once it is properly erased, (reformatted) everything works fine.  Your comment makes me wonder if the erase part of Upgrade And Erase doesn't work, at least sometimes, but Rescue Erase does work.

But what's nagging me is that -IMHO- if caused by a low spec/faulty mem chip, I'd expect random errors. It wouldn't work in exactly the same way on every 'faulty' CC3D, would it?

It's quite possible for the chip's internal erase circuit to not work well and the rest of the flash chip to work fine.

[Penthane]

So now, even your "bad" CC3Ds work correctly ... and LP EraseSettings does erase?

Yes, they do. They work and LP-Erase works too. It really looks like CF does erase something LP doesn't.

maybe did you U instead of U&E?

No. I always use U&E. Might miss-click sometimes, but not with 6 FC's in a row. I'm not thát old 

<cut> if the erase part of Upgrade And Erase doesn't work, at least sometimes, but Rescue Erase does work.

Maybe, but not likely. I only started using RE once I had this problem. But I certainly did try RE before I used the CF-Erase method.

It's quite possible for the chip's internal erase circuit to not work well and the rest of the flash chip to work fine.

But then all 'bad' -not saving-  CC3D's would have exactly the same defect? On the other hand; CF doesn't use ext mem, except for logging. LP does use ext mem for it's main program, am I right? So, CF erases ext mem while itself active in main mem and LP erases ext mem while itself being (partly) active on it. So CF-erase can completely wipe ext mem, but LP can only wipe settings area and not everything in ext mem, because it's active in ext mem and would wipe part of itself?

Did you flash the bootloader and that made them work?

Can't say. I flashed BF because BF could not connect to CC3D with LP on it (failed to open port). So I flashed BF to get it to connect. Which worked. With BF on, it connected immediately. Then I erased through CLI, replugged to check if CC3D worked, unplugged, switched to LP, U&E and plugged CC3D in. Replugged and it worked, but some of the other CC3D's had no problem connecting with BF while LP was on it and were erased from BF without flashing BF on. After CF-Erase (some twice, the last one even 5 or 6 times) they all work fine with LP, Erase included.

[TheOtherCliff]

CF uses external flash for logging.  LP uses it for settings.  Neither use it for program.  There is special internal memory for program storage.

Besides UpgradeAndErase and RescueErase there is HaltErase.

But then all 'bad' -not saving-  CC3D's would have exactly the same defect?

Not the same defect... the same "junk data" that partially fills the "disk" so that install fails part way through, or completely fills the "disk" and the first time (mixer settings?) you try to write the settings from memory to flash it fails.

I flashed BF to get it to connect. Which worked. With BF on, it connected immediately. Then I erased through CLI, replugged to check if CC3D worked, unplugged, switched to LP, U&E and plugged CC3D in. Replugged and it worked

Either BF puts it's own LP compatible bootloader on (and that is a possible problem) or it just uses the bootloader that is there because you would have to do special things to put an LP bootloader on if CF/BF overwrote it.  The fact that you could use LP GCS to UpgradeAndErase indicates there was an LP (compatible) bootloader on it.

By your own comments, if LP needed something special erased, then the first time you erased with CF/BF the special area would be erased.

Where there any "bad" CC3D's that you know that all you did was BF/CF flash_erase several times (no BF/CF firmware).  What did you use (BF or CF) (flash_erase or flash and run BF/CF firmware) in this last go round that seems to have fixed them all?  Any best guess?

Is there anything you can think of that you did that finally made the bad ones good?
- Flashing BF vs. CF firmware
- Booting BF/CF firmware.
- Using BF vs. CF to flash_erase
- Waiting longer for the BF/CF flash_erase before powering off
- Old version bootloader that got upgraded when you were doing BF/CF flashing stuff.  LP updates the bootloader code to V4 and then BF/CF does and finally (maybe never) the CC3D cloners do so it could have had an old LP or LP compatible BF/CF bootloader on it.
- Bad flash chip that gets better after being erased several times.
- Finally waited long enough before power off with CF flash_erase.  I don't know how long it takes.

I can tell you that a few years ago there was a known issue that installing and running CF/BF firmware would format the flash to be used for CF/BF logging and that would mess it up where LP would not boot (until you erased the flash).  I also wrote a change for the LP firmware (I don't think we included CC3D) to automatically unbrick this particular case.  I can tell you that a complete unbricking took 10's of seconds the way we do the erase flash.

[Penthane]

Where there any "bad" CC3D's that you know that all you did was BF/CF erase flash several times (no BF/CF firmware).  What did you use (BF or CF) (erase flash or flash and run BF/CF firmware) in this last go round that seems to have fixed them all?  Any best guess?

Yes, one of 'em only needed one "CLI: Flash_Erase". It connected with BF without the need to flash BF on and a single Flash_Erase was enough. Problem is, all devices look the same and I don't number them (  ), so I have no idea which one.
I still have a feeling that it has to do with arming. Don't know why, it's just a feeling, but the CC3D's behave like they are 'Always Armed'. The whole way they react is the same as if you try to change something while armed.

Is there anything you can think of that you did that finally made the bad ones good?
- Flashing BF vs. CF firmware
- Booting BF/CF firmware.
- Using BF vs. CF to erase flash
- Waiting longer for the BF/CF erase flash before powering off

I really can't tell. You see, You started out trying to identify the exact problem, while I was only trying different internet found solutions (in between working on my bathroom)  to try to get some (some already refunded) 'defective FC's' working, as a way of taking my mind off the bathroom for a while. I was not systematically searching. I've done all of the above, but I don't know what I did to which one. After ev'ry 'session' with the CC3D's I just put them all back in a drawer. It's only when you started asking things that I really started to pay attention.

- Old version bootloader that got upgraded when you were doing BF/CF flashing stuff.  LP updates the bootloader code to V4 and then BF/CF does and finally (maybe never) the CC3D cloners do so it could have had an old LP or LP compatible BF/CF bootloader on it.

I remember two I bought last summer, that 'functioned' out of the box, but the last two seemed to have nothing on it. If I remember correctly, they only had a weak, slow blinking blue led. To get them to do anything, I U&E'd them by pressing U&E on fw-tab (1609) and then connect device. When they came to live,they all had BL4.

- Bad flash chip that gets better after being erased several times.

Until they fail completely probably.

- Finally waited long enough before power off with CF erase flash.  I don't know how long it takes.

I always wait for Atti & Stab to turn green. That should be long enough?

[Penthane]

Damn! I was fiddling with a 'revived' CC3D just now and I'm really sorry, but it seems I've been 'lying' to you the whole time. I used a 'bad' CC3d in a new plane and found that though it looks like it is Armed, it is NOT! I get a green tick when saving 'Always Armed', and when rebooted, it says it's Armed, but my motor doesn't run! I tried 'Test Outputs' in Output-tab before to check and it all worked fine. I stupidly never checked if, after arming, my motor would run. Guess I was just too happy with a Green Tick after only seeing  Red Crosses 'till then.

So, I have a booting, working CC3D, that at first wouldn't save any settings, that now -after erasing with BF (I only use BF. CF doesn't connect) does save settings, but though it seems to arm normally (green tick), in reality doesn't. But 'Test Outputs' does arm the motor! So it says it's armed, but isn't???

I have tested the other one of the last shipment and it's the same! It says it's armed, but the motor doesn't run. Again, Test Outputs makes it spin like a .. cat?

I think I'm ready to throw the towel and send them back/ask for a refund.

[TheOtherCliff]

Yes, one of 'em only needed one "CLI: Flash_Erase". It connected with BF without the need to flash BF on and a single Flash_Erase was enough.

This info helps.  It says that you did not have to flash any firmware to "fix" at least one.

I remember two I bought last summer, that 'functioned' out of the box, but the last two seemed to have nothing on it. If I remember correctly, they only had a weak, slow blinking blue led. To get them to do anything, I U&E'd them by pressing U&E on fw-tab (1609) and then connect device. When they came to live,they all had BL4.

Weak slow blinking (fades on and off) LED says that it has a bootloader, but does not have any flight firmware.

At this point, I wonder if the cloners use a version of BL4 that is not the same as LP's BL4.  I forget, have you flashed LP's BL4 onto any of them?

[TheOtherCliff]

It says it's armed, but the motor doesn't run. Again, Test Outputs makes it spin like a .. cat?

By "like a cat" I guess you mean spin correctly. 

If you post the CC3D settings (File->ExportUAVSettings with CC3D plugged in), we can look at it and see what might keep the throttle from working.

I wouldn't give up.  The motor(s) run(s).  It should be a simple thing to figure out at this point. Forgive me for being very complete in the following descriptions.  I've undoubtedly included things you already know and do.:
- Flight battery needs to be plugged in (or RC receiver doesn't get powered). 
- With flight battery and USB/GCS plugged in, and transmitter on you can go to Input (->RC Input) page and see the sliders move according to the transmitter sticks.  Make sure the throttle slider moves when you move the transmitter stick.
- Are you using "Always Armed"?  This is a minor pain because any change you want to make, you must first turn off "Always Armed", then make the change, then turn on "Always Armed".
- If not using Always Armed but using "Throttle off and X" then you must be able to get to absolutely 0 throttle and full "X".  A little bit of transmitter trim or dual rate or channel offset, etc. might keep you from getting zero throttle and full "X".  And you must hold the "Throttle off and X" for a whole second.
- It won't arm if there is an alarm or you have GPS Assist or AltitudeVario or AltitudeHold or some cases of AlwaysStabilizeWhenArmed, etc.
- Some ESCs require a zero throttle, full throttle, zero throttle cycle each time you plug a battery in.  Not usable for a quad, but maybe you have one of these in an airplane?

Some of these don't apply to CC3D, but trying to enable them would still cause arming problems.

Is all your stuff airplanes using AlwaysArmed?

[Penthane]

By "like a cat" I guess you mean spin correctly.

I forgot, cats don't spin in English, they purr In Dutch cats's purring sound is called 'spinnen'. So I meant the motor runs smooth. It purrs like a cat.

I found the culprit. RX plug wasn't seated properly. Motor(s) running now!

Is all your stuff airplanes using AlwaysArmed?

Yes! All except for my drone. It has a 10-ch RX and has plenty of CH's to spare for an Accessory-Arm. Which works for drones, but with planes one uses long periodes of full rudder/elevator frequently and I don't want to shut down my motor mid air    I have some that glide pretty well, but not all do and I regularly fly above a city lake nearby. Foamies don't sink easily, but it takes forever to get them back ashore. I don't  own a 1:1 boat and my rc hydroplanes have no reverse, so most times they're pretty useless as a tow   Using  6-CH RX's for my planes, I use my spare CH for flaps or a (tow) hook.

At this point, I wonder if the cloners use a version of BL4 that is not the same as LP's BL4.  I forget, have you flashed LP's BL4 onto any of them?

Yes, I think I did them all, because I wanted to rule out a bad BL or fw. I used 'bu_CC3D-20120620_f44b9d3.opfw' and followed the instructions on the Wiki page ( https://opwiki.readthedocs.io/en/latest/appendices/bootloader.html ). But it didn't solve the problem. At least I didn't notice any difference, but that doesn't say there were none.

[TheOtherCliff]

At this point, I wonder if the cloners use a version of BL4 that is not the same as LP's BL4.  I forget, have you flashed LP's BL4 onto any of them?

Yes, I think I did them all, because I wanted to rule out a bad BL or fw. I used 'bu_CC3D-20120620_f44b9d3.opfw' and followed the instructions on the Wiki page ( https://opwiki.readthedocs.io/en/latest/appendices/bootloader.html ). But it didn't solve the problem. At least I didn't notice any difference, but that doesn't say there were none.

So, even after making sure it was running LP BL4 you still had the problem.  Thank you.  This is good information.

When CC3D was "bad" and you tried erasing with LP Erase or UpdateAndErase, did you get any error message or other indication of error?  Sorry if you answered this before and I forgot.

[Penthane]

Nope, no indication, no errors. I remember hooking up the first of the last two and getting the slow pulsing blue LED. I clicked U&E in FW-tab and it said it couldn't get device in bootloader mode (not unusual) and to do a manual update, so I disconnected USB, closed LP, restarted LP, clicked Rescue, then U&E and connected USB. All went as expected. After U&E finished, I dis- and reconnected and all seemed well. I ran the setup Wizard and up 'till setting mixes it all ran fine, then GCS got stuck. I rebooted and my settings were gone. So I hooked up the other one and got exactly the same results. That's when I started looking for a way to get the CC3D's working and I found the CF/BF method.

I wouldn't give up.  The motor(s) run(s).  It should be a simple thing to figure out at this point.

I never do. I get frustrated and to prevent great damage to things around me, I quit! For a while at least, but I always get back on it.

[TheOtherCliff]

Let me say to anyone that has this problem to please just try LP Erase again, but make sure that after clicking that OK button, that you wait for the board to actually reboot itself and connect itself back to GCS, before doing anything else.  It should take less than a minute.  Do NOT just wait a little while, see that the blinking is not changing, and unplug the board.

I bought a CC3D Atom from eBay ($9 shipped) recently and thought I would try to recreate this issue.
https://www.ebay.com/itm/Openpilot-Mini-CC3D-Atom-Nano-CC3D-Flight-Control-for-FPV-QAV-ED/122116570993

Short version: I did not Erase Settings and I did have a very similar sounding problem with it with LP 16.09, but LP Erase Settings fixed the problem.

It came with this firmware on it:
  Firmware version: 20150512 23:55 (29b92655-ffca2cd6)
  Device ID: 402
  HW Revision: 2
  Flash access: RW
  BL version: 4
  Max code size: 118684
  RELEASE-15.02.02
  CRC: 1160622165

I copied off the old firmware using Firmware->Retrieve and flashed 16.09 on it and did NOT Erase Settings.  I verified (in System->AccelGyroSettings->accel_bias) that the level calibration was all zeros.  I did a level calibration on it, Saved (OK), verified the calibration numbers were not zeros, and exported it.  It exported OK.

I made a copy of the settings file and modified a number in each UAVO.  When I tried to import these modified settings it locked up at 2%.  After 5-10 minutes of it sitting at 2% (green LED on, blue LED slowly fading on and off), I rebooted and exported the settings and found that nothing had changed.  It was all defaults except for the leveling calibration I made.  So note that the first Save (after leveling calibration) did appear to work OK (was indeed saved permanently).

I erased settings (Halt, Erase Settings) normally with GCS and now everything is working.  I can say that the erase took longer than I expected (probably less than a minute though, and it had been a while since I had done an Erase Settings), but I didn't time it.  I was getting tempted to just unplug the board when it finally booted and connected to GCS.

I imported settings: stock, modified, stock, modified, ... etc. a total of 16 imports with no problems, so I gave that up.

I put the old firmware back on it, Erased Settings, and booted it; then put 16.09 back on it and repeated my initial steps (level calibration, save, etc., export, import) and had zero problems, so at least for me it was something strange on the flash (settings storage) that got fixed with a standard 16.09 LP GCS Erase Settings (Halt, Erase Settings).

I know that the flash "file system format" changed, maybe between BL3 and BL4.  I wonder if this is what happens when you have the old flash file system?  16.09 / BL4 writes the new format.  In BL4 at least the firmware is asked to reboot in safe mode and format the flash with format code in the firmware.

I'm thinking of buying another of these Atoms, and writing some code to save/restore all of the flash device.
Update: I bought another Atom from the same place, and started by reading the whole settings EEPROM, but I could not recreate the issue at all.  There are some kinds of garbage data that would cause this "settings file system corruption", so that is my current working theory.    LibrePilot "Erase Settings" should fix any "settings file system corruption".

[Penthane]

Bathroom finished   

I'll try the LP Erase again next time. Did the CF/BF trick again a few days ago. Controller came from a crashed plane, so I had to set it up for it's next 'home' ( http://www.aero-news.net/images/content/general/2013/Velocity-V-Twin-0413a.jpg ) and it didn't save again. I'm not a very patient person anymore, so could be that I don't wait long enough.

You actually bought a Chinese CC3D to experiment?    KUDOS for your effort!

[TheOtherCliff]

You actually bought a Chinese CC3D to experiment?

  I bought the Atom as a cheap controller to experiment with a small fast plane and I thought I would try to recreate the issue.

[solmer]

THANK YOU SO MUCH! yes I'm using uppercase because your post saved my CC3D

Good fly!