OK let us try again;

Reflashed and recalibrated accelerometer.

Went straight to Blackbox and successfully erased the dataflash memory. memory now clear with 8.0 Mb available.

Now the question is....do I dare save and reboot?

I did and here is the log file. I think this proves pretty conclusively that the problem occurs during the rebooting.  WHY?

I checked the port all the way through this stuff and it never changed from Port 5 on the DV and Beta config. Nor could I manually reconnect.

Another reflash looming.  

UGH! UGH! UGH! 

[color=rgba(255, 255, 255, 0.6)]
2018-01-19 @ 15:24:47 -- Loaded release information for configurator from GitHub.[/color]
[color=rgba(255, 255, 255, 0.6)]2018-01-19 @ 15:24:49 -- Serial port successfully opened with ID: 1[/color]
[color=rgba(255, 255, 255, 0.6)]2018-01-19 @ 15:24:59 -- No configuration received within 10 seconds, communication failed[/color]
[color=rgba(255, 255, 255, 0.6)]2018-01-19 @ 15:24:59 -- Serial port successfully closed[/color]
[color=rgba(255, 255, 255, 0.6)]2018-01-19 @ 15:27:48 -- Serial port successfully opened with ID: 2[/color]
[color=rgba(255, 255, 255, 0.6)]2018-01-19 @ 15:27:58 -- No configuration received within 10 seconds, communication failed[/color]
[color=rgba(255, 255, 255, 0.6)]2018-01-19 @ 15:27:58 -- Serial port successfully closed[/color]
[color=rgba(255, 255, 255, 0.6)]2018-01-19 @ 15:39:01 -- Loaded release information for firmware from GitHub.[/color]
[color=rgba(255, 255, 255, 0.6)]2018-01-19 @ 15:40:58 -- Serial port successfully opened with ID: 4[/color]
[color=rgba(255, 255, 255, 0.6)]2018-01-19 @ 15:40:58 -- MultiWii API version: 1.36.0[/color]
[color=rgba(255, 255, 255, 0.6)]2018-01-19 @ 15:40:58 -- Flight controller info, identifier: BTFL, version: 3.2.1[/color]
[color=rgba(255, 255, 255, 0.6)]2018-01-19 @ 15:40:58 -- Running firmware released on: Oct 15 2017 19:48:10[/color]
[color=rgba(255, 255, 255, 0.6)]2018-01-19 @ 15:40:58 -- Board: SRF3, version: 0[/color]
[color=rgba(255, 255, 255, 0.6)]2018-01-19 @ 15:40:58 -- Unique device ID: 0x2c002e4134570820333634[/color]
[color=rgba(255, 255, 255, 0.6)]2018-01-19 @ 15:40:58 -- Craft name:[/color]
[color=rgba(255, 255, 255, 0.6)]2018-01-19 @ 15:41:34 -- CLI mode detected[/color]
[color=rgba(255, 255, 255, 0.6)]2018-01-19 @ 15:52:14 -- Serial port successfully closed[/color]
[color=rgba(255, 255, 255, 0.6)]2018-01-19 @ 16:22:09 -- Serial port successfully opened with ID: 5[/color]
[color=rgba(255, 255, 255, 0.6)]2018-01-19 @ 16:22:19 -- No configuration received within 10 seconds, communication failed[/color]
[color=rgba(255, 255, 255, 0.6)]2018-01-19 @ 16:22:19 -- Serial port successfully closed[/color]
[color=rgba(255, 255, 255, 0.6)]2018-01-19 @ 16:22:44 -- Using cached release information for firmware releases.[/color]
[color=rgba(255, 255, 255, 0.6)]2018-01-19 @ 16:25:27 -- Serial port successfully opened with ID: 13[/color]
[color=rgba(255, 255, 255, 0.6)]2018-01-19 @ 16:25:27 -- MultiWii API version: 1.36.0[/color]
[color=rgba(255, 255, 255, 0.6)]2018-01-19 @ 16:25:27 -- Flight controller info, identifier: BTFL, version: 3.2.4[/color]
[color=rgba(255, 255, 255, 0.6)]2018-01-19 @ 16:25:27 -- Running firmware released on: Jan 10 2018 23:09:29[/color]
[color=rgba(255, 255, 255, 0.6)]2018-01-19 @ 16:25:27 -- Board: SRF3, version: 0[/color]
[color=rgba(255, 255, 255, 0.6)]2018-01-19 @ 16:25:27 -- Unique device ID: 0x2c002e4134570820333634[/color]
[color=rgba(255, 255, 255, 0.6)]2018-01-19 @ 16:25:27 -- Craft name:[/color]
[color=rgba(255, 255, 255, 0.6)]2018-01-19 @ 16:25:38 -- Accelerometer calibration started[/color]
[color=rgba(255, 255, 255, 0.6)]2018-01-19 @ 16:25:40 -- Accelerometer calibration finished[/color]
[color=rgba(255, 255, 255, 0.6)]2018-01-19 @ 16:30:47 -- EEPROM saved[/color]
[color=rgba(255, 255, 255, 0.6)]2018-01-19 @ 16:30:47 -- Device - Rebooting[/color]
[color=rgba(255, 255, 255, 0.6)]2018-01-19 @ 16:31:03 -- Serial port successfully closed[/color]
[color=rgba(255, 255, 255, 0.6)]2018-01-19 @ 16:31:07 -- Serial port successfully opened with ID: 14[/color]
[color=rgba(255, 255, 255, 0.6)]2018-01-19 @ 16:31:17 -- No configuration received within 10 seconds, communication failed[/color]
[color=rgba(255, 255, 255, 0.6)]2018-01-19 @ 16:31:17 -- Serial port successfully closed[/color]

(19-Jan-2018, 05:42 AM)Tom BD Bad Wrote: go into CLI and type -
dump

It should show a lot more info than what you have posted?


I was trying to update an F3 FC the other day, despite the configurator working and saving changes in the settings, when I tried to flash the updated FW, BetaFlight would change the COM port. When I tried to reconnect, the COM port that was being used was no longer available, and I had to 'un' and 're' plug the board for the PC to recognize the connection.

Downloading and reinstalling zadig fixed this. - thanks to voodoo for helping me get that sorted.

Thanks BD.

I am not having any port problems and I can reflash successfully each time.

I am satisfied my problem arises when I ask the SP F3 to save and reboot.

At that point I get the waiting for data signal and I am locked out after that and can only regain access by reflashing the firmware.

Now the question is "Why does the reboot sequence go crazy?"

Weird wot?  

KK

Howdy Boys,

One last time. I have repeated the reflash over and over with both Beta and Clean firmware and there is absolutely no doubt that my problem is associated with the reboot sequence.

Below is a small segment of the Log showing quite clearly the save was successful but there was no progress after the reboot.

Going back to how all of this started it began when I made the error of saving UART3 instead of UART1.

Is there any possibility that this error is still residing in the FC somehow.

Otherwise I am at a complete loss as to where to go from here.

Any ideas lads?  
[color=rgba(255, 255, 255, 0.6)]
2018-01-20 @ 13:08:16 -- Using cached release information for firmware releases.
2018-01-20 @ 13:10:37 -- Serial port successfully opened with ID: 11
2018-01-20 @ 13:10:37 -- MultiWii API version: 1.31.0
2018-01-20 @ 13:10:37 -- Flight controller info, identifier: BTFL, version: 3.1.2
2018-01-20 @ 13:10:37 -- Running firmware released on: Feb 2 2017 00:02:30
2018-01-20 @ 13:10:37 -- Board: SRF3, version: 0
2018-01-20 @ 13:10:37 -- Unique device ID: 0x2c002e4134570820333634
2018-01-20 @ 13:10:37 -- Craft name:
2018-01-20 @ 13:10:47 -- Accelerometer calibration started
2018-01-20 @ 13:10:49 -- Accelerometer calibration finished
2018-01-20 @ 13:12:47 -- EEPROM saved
2018-01-20 @ 13:12:48 -- Device - Rebooting
2018-01-20 @ 13:13:19 -- Serial port successfully closed[/color]

KK try the CLI command -
diff all showdefaults

I am not sure what is going on with this info you are getting? The CLI 'dump' command should produce over 300 lines of configurable settings for your FC!?

Check the 1st post of this thread, the box with the heading 'Code :' will show you what a CLI dump should look like.

(20-Jan-2018, 04:44 AM)Tom BD Bad Wrote: KK try the CLI command -
diff all showdefaults

I am not sure what is going on with this info you are getting? The CLI 'dump' command should produce over 300 lines of configurable settings for your FC!?

Check the 1st post of this thread, the box with the heading 'Code :' will show you what a CLI dump should look like.

Hi BD, that info is the Log file located at the very top of the Beta/Clean configurators just under the auto-connect switch and it shows all of the activity that takes place after you connect the FC to the configurator. Normally you can only see 1 - 4 lines at a time but I have copied and pasted several full files.

The CLI file is something entirely different and I have tried to post the CLI file as an attachment but IntoFPV will not accept that type of file as an attachment.

I am not sure how to get that CLI file to you. Do you know?

Regards,

KK

if you type -
"code" within [square brackets]
then paste the info from the dump
and type
"/code" within [/square brackets] at the end of the info

Wow, editing that post was a pain!

In the CLI screen you can left click and hold to highlight the text in the dump and press Ctrl + C to copy it.

(20-Jan-2018, 06:56 AM)Tom BD Bad Wrote: wow editing that post was a pain!

Hi BD, I assume you are talking about posting the CLI file on IntoFPV?

From the bottom tab in Betaflight configurator

   

Click 'save to file' in the bottom right corner, it will save as a .txt file, choose to save to desktop so you can find it, open the file and copy the text...

(20-Jan-2018, 07:03 AM)Keyboard Kid Wrote: Hi BD, I assume you are talking about posting the CLI file on IntoFPV?

Sorry I mis-read! 

Yes post the info from the saved .txt file using the box method above.

(20-Jan-2018, 07:17 AM)Tom BD Bad Wrote: Sorry I mis-read! 

Yes post the info from the saved .txt file using the box method above.

Hi BD,

I reflashed (again) and went through setting up as many parameters as I could that would actually save without rebooting.

I then went to the CLI tab and typed in "Dump" and up came a very long list of details.

I then clicked on the "Save to file" tab and then opened the saved Text file to ensure that it was a valid file.

That it was.

So I now have a valid CLI dump file in TXT format and 14K in size.

The only problem is I am not sure of your instructions on posting that file.

Sorry old boy but it is all pretty mysterious to me.     Let me see if I have got this right.

In the new post box I start with a square bracket and code/ insert the TXT file name and close with /code and close square bracket?

Correct?

Not quite.

The opening and closing tags look like this: (without the spaces)

[ code ]
[ /code ]

Also, please ignore Tom's advice about zadig.

The SP Racing F3 uses a CP2102 UART to USB bridge chip and does not need any other drivers than the CP2102 driver you already have.

Zadig is only used for flight controllers which use the virtual USB serial port provided by the MCU.

I have to say that I'm mystified by why your flight controller won't come back after a reboot.

However, looking back in the thread I found the photo that you posted of your flight controller which says that it has an integrated OSD. This is not a genuine SP Racing F3 flight controller as they were never made by Dominic Clifton with an integrated OSD. This leads me to wondering how the OSD is connected to the flight controller and how it is enabled and disabled.

One way of doing it is that the OSD and the flight controller both share UART1 (the UART that talks to the USB port via the CP2102 chip). Normally, this works fine as when the flight controller is only powered by the USB port, no power is supplied to the smaller microprocessor that runs the OSD. Once you plug the flight battery in, the OSD gets power and starts to read the MSP data from the UART.

If this is the case, you can only use the USB port when the flight battery is disconnected.

Do you have a link to where you bought this flight controller from?

(20-Jan-2018, 11:59 AM)unseen Wrote: Also, please ignore Tom's advice about zadig.

The SP Racing F3 uses a CP2102 UART to USB bridge chip and does not need any other drivers than the CP2102 driver you already have.

Zadig is only used for flight controllers which use the virtual USB serial port provided by the MCU.

I have to say that I'm mystified by why your flight controller won't come back after a reboot.

However, looking back in the thread I found the photo that you posted of your flight controller which says that it has an integrated OSD. This is not a genuine SP Racing F3 flight controller as they were never made by Dominic Clifton with an integrated OSD. This leads me to wondering how the OSD is connected to the flight controller and how it is enabled and disabled.

One way of doing it is that the OSD and the flight controller both share UART1 (the UART that talks to the USB port via the CP2102 chip). Normally, this works fine as when the flight controller is only powered by the USB port, no power is supplied to the smaller microprocessor that runs the OSD. Once you plug the flight battery in, the OSD gets power and starts to read the MSP data from the UART.

If this is the case, you can only use the USB port when the flight battery is disconnected.

Do you have a link to where you bought this flight controller from?

Hi Unseen,

I am  not sure about that driver. My DM just says "Silicon Labs CP210x USB to UART bridge (Com5)". I did try to instal the CP2102 but it coming up as shown at the start of this line of text. I had real trouble finding and installing that CP2102.

You are correct in that my FC is an SP Racing F3 with built in OSD purchased from Hobby King.

I did not realise that there was a genuine  SP F3 and a copy. Had I known I would have chased after the real one. I do not need the OSD anyway.

I did try one interesting test in that I reflashed (for the 623 time) and entered several parameters and saved them without rebooting and then I disconnected the USB. I then reconnected and the data I entered and saved appeared in the correct position once again proving that the reboot is the problem.

With regards to using the USB connection with the flight battery plugged in, the USB worked perfectly normally with or without the flight battery plugged in.

I must say I am terribly suspicious of that UART 1 and UART 3 thing. The manual did say that the SP usually uses UART3.

I must also say that i feel completely out of my depth with all of this stuff and that you were right when you said that I need hands on help.


That is pretty obvious now.

Regards,

KK