A serious bug has been discovered in RC6 where bad registers can potentially be written to ICM-20689 gyros causing PERMANENT LOSS OF THE YAW AXIS. It is strongly recommended you DO NOT flash RC6 on FCs that use the ICM-20689 gyro. If you are unsure, type 'status' in the Betaflight CLI to see what gyro the board has.

I know a number of people who have experienced this issue recently, and luckily it also affected one of the BF devs who was able to track the issue down. 

https://github.com/betaflight/betaflight/pull/11584

Quote:There have been reports of the yaw axis becoming unresponsive on the ICM-20689 gyro. Once this occurs the change is persistent across power cycles and reverting to old firmware versions has no effect. I have been able to restore the functionality of one such affected gyro by writing values to undocumented registers (as read from a good gyro), but this was very hit and miss and has failed to recover another gyro.

It is believed that this issue is being caused by an inadvertent write to a reserved register.

A support case is ongoing with TDK.

Meanwhile I have reviewed the startup code and this PR fixes the following issues:

SPI clock was set to a max of 10MHz. When I had a gyro go bad it was being clocked at 6.75MHz (derived from 108MHz overclocked F411) so this wasn't the cause of this issue, but nevertheless this PR drops the max clock speed to 8MHz as per the data sheet.
The detect routines for the supported gyros are called in turn and the MPU6500 driver was performing accesses with an SPI clock of 20MHz (MPU6500_MAX_SPI_CLK_HZ) which could have caused erroneous register accesses. This has been reduced to 1MHz (MPU6500_MAX_SPI_INIT_CLK_HZ).
Section 6.1 of the data sheet states that I2C_IF_DIS should be set immediately after reset to avoid the device switching to I2C mode which we were not doing. This is now done once the WHO_AM_I register has been read and validated.
The mpu6000SpiDetect() routine was writing to the SIGNAL_PATH_RESET register, setting bit 2 which is a reserved bit in the ICM-20689. This write is now only performed once the MPU6000's identity has been confirmed.
There were unnecessary delays between register writes which have now been reviewed, eliminated where possible, and adjusted where needed, with comments justifying the delay values.

The question that needs to be asked here is why is Betaflight even trying to WRITE any data to the gyro at all? Surely it should only ever be READING data from the gyro, so that issue seems to be a massive balls-up, especially if it's managing to irrecoverably destroy the gyro in the process.

Is this only an issue with RC6, or is it a potential issue with all RCs?

(11-May-2022, 10:48 PM)SnowLeopardFPV Wrote: The question that needs to be asked here is why is Betaflight even trying to WRITE any data to the gyro at all? Surely it should only ever be READING data from the gyro, so that issue seems to be a massive balls-up, especially if it's managing to irrecoverably destroy the gyro in the process.

It looks like some undocumented register behavior from the vendor for this particular gyro.

Quote:

Quote:The mpu6000SpiDetect() routine was writing to the SIGNAL_PATH_RESET register, setting bit 2 which is a reserved bit in the ICM-20689. This write is now only performed once the MPU6000's identity has been confirmed.

Looks like the BF code does write to determine GYRO type or status and in doing so with a poor timing on the CLK has caused erroneous register writes to the gyro and killing it for that axis.

I dunno, this is how I've interpreted it.  I'm mainly a hardware EE, not a software EE.

lol..

(11-May-2022, 11:30 PM)Lemonyleprosy Wrote: Is this only an issue with RC6, or is it a potential issue with all RCs?

I'd say only RC6 but given the way the release milestones are going, who knows!  that's why I've left the testing on the small quads before I went and updated the rooster.

The official recommendation is to stay at RC5, but since it's not clear exactly when the bug was introduced, I personally am running the latest commit with the above PR merged (9e89458) on my ICM20689 boards.

Below are a list of the FC's I have found that host one or more ICM20689 Gyro chips. Other FC's on the market host an MPU6000, ICM20602, or BMI270 Gyro chip, none of which appear to be affected by this bug.

• Flywoo GOKU F405 & F7 boards
  
• GEPRC Stable F7 boards
  
• iFlight SucceX-D F7 boards
  
• JHEMCU F7 boards
  
• NXTF7 boards
  

(12-May-2022, 02:21 AM)SnowLeopardFPV Wrote: Below are a list of the FC's I have found that host one or more ICM20689 Gyro chips. Other FC's on the market host an MPU6000, ICM20602, or BMI270 Gyro chip, none of which appear to be affected by this bug.

• Flywoo GOKU F405 & F7 boards
  
• GEPRC Stable F7 boards
  
• iFlight SucceX-D F7 boards
  
• JHEMCU F7 boards
  
• NXTF7 boards
  

Not all of these FCs have an ICM20689 gyro, and this is not an exhaustive list. None of my Flywoo Goku boards use this gyro, for example. However, some of the new BetaFPV AIOs do use the ICM20689.

If you're not sure, just type 'status' in the Betaflight CLI and see what it says after 'GYRO:'.

One of the devs confirmed the issue also existed on RC5, so if you have a board with the ICM20689 gyro I still think the safest course of action is to update to master with the above PR merged.

Edit: Alternately, Betaflight 4.2 and earlier should be safe if you don't need BF4.3 for some reason (eg ELRS SPI boards).

Here is an example of what to select in Betaflight Configurator to flash the latest version of BF 4.3.0 with the above PR merged:

   

V-22, is the #2694 version usable as well? I flashed #2693 on mine, as instructed, but it said a new version had come out on the 18th. I wasn't sure whether to use it, so I didn't.

Fixes are cumulative so you should be fine. I flashed the 18th of may build onto a jhemcu ghg413 f411 FC and it is working well.

Ok cool. Thanks.

Just be aware that cumulative fixes to nightly builds can also introduce (or reintroduce) other bugs. It's one of the (calculated) risks you have to take when running development builds. If you find a dev build with a known issue confirmed to have be fixed in it, then it is probably wise to stay on that particular dev build unless you know a newer build has a fix for something else you need (i.e. don't keep updating the dev build on your FC to the next newest version every day unless you have a specific need to).

Yeah, as much as I can do testing on bleeding edge, I would prefer stable if I can. If this version works for me I probably won't upgrade again until 4.4, or some feature that is required is added.