MPU-6000 vs ICM-42688-P: migrating off the obsolete IMU (2026)
Engineers migrating off the MPU-6000 reach for the ICM-42688-P as the current TDK 6-axis part they most commonly move to, but it sits in a different package with a different register map, so a board and driver built around the MPU-6000 needs a re-layout and a new driver before the ICM-42688-P will run. A 6-axis IMU is defined by its register map and its footprint, not by its axis count or its shared TDK lineage.
This page compares the MPU-6000 against the crosses engineers actually weigh: mpu6000 vs icm42688p, mpu6000 vs bmi270 and mpu6000 vs mpu6050, where the obvious I2C sibling, the MPU-6050, is itself obsolete. Suggested candidates to validate in your own design, not drop-in equivalents.
Status // The part in question
Lifecycle status
The MPU-6000 is obsolete, on TDK's own status field. TDK's Product Center part page renders Product Status as “Obsolete” for the MPU-6000; the live page blocks automated fetches, so the status word here is read from the archived capture dated 2025-11-15. The maker's status field is the confirmed basis; a live distributor status line is worth pulling on publish day as corroboration, and no cross-source disagreement has surfaced.
The status comes from the maker's own field rather than a distributor flag on an otherwise live part, so the work is a migration. Broker and last-time-buy stock still surfaces, and it defers the migration without removing the requalification: every cross below changes the package, the register map, or both. A last-time buy runs in parallel with the design-in of one named cross, and the requalification is budgeted either way.
Current stock levels, broker availability and pricing are point-in-time figures, kept off this evergreen page.
Candidates // Why these
The candidate set
Three crosses, each with the fit-catch to validate in your own design. The MPU-6000 core, for reference: a 6-axis MEMS device combining a 3-axis gyroscope and a 3-axis accelerometer, with both SPI (to 20MHz on the sensor and interrupt registers) and I2C, in a 24-pin QFN measuring 4×4×0.9mm, on the register map documented as RM-MPU-6000A.
Catch: a different part, not a drop-in. The part mpu6000 vs icm42688p searches, and the current TDK 6-axis part these migrations most commonly target. Both the footprint and the pin count change from the QFN-24 MPU-6000, and its bank-switched register architecture answers with a different WHO_AM_I identity, so the MPU-6000 driver will not enumerate or configure it without a rewrite.
Catch: an init step your design has no equivalent for. The part mpu6000 vs bmi270 searches, cross-shopped as the non-TDK path. Beyond a different vendor register map, the BMI270 requires a configuration file of roughly 8KB burst-uploaded to its feature engine after every power-on or soft reset before motion output is valid.
Catch: the only register-map match, and itself obsolete. The part mpu6000 vs mpu6050 searches. The MPU-6050 is the I2C-only sibling of the MPU-6000 and shares the RM-MPU-6000A register map, which is exactly why it reads as the obvious like-for-like cross. It is discontinued at TDK, so crossing to it relocates the obsolescence rather than solving it. It is listed here to close off that cross.
Identity // What the migration actually costs
Same job, not the same footprint or register map
Pinout is not the axis here. The MPU-6000 is a 24-pin QFN, the ICM-42688-P and the BMI270 are 14-pin LGA parts, and no active cross shares the MPU-6000 footprint or pin count, so a per-pin map is not meaningful across the set and every cross is a board re-layout, not a footprint swap.
A parametric search cannot return what actually decides the cross. A distributor cross-reference filters by function, interface and full-scale range and hands back all of these parts, but the real cost is firmware and bring-up work, and that is not a filterable column. Firmware keyed to the MPU-6000 register map, its WHO_AM_I identity value and its FIFO packet format stops matching the moment the silicon changes:
Migration work to scope, per cross · not a parametric comparison
The MPU-6050 is absent from this table because it is not a migration target. It keeps the MPU-6000 footprint and the RM-MPU-6000A register map, but it is itself obsolete, a reference cross to rule out, not migration work to scope.
The register map and the footprint are the two things the cross-reference will not tell you. Every active cross changes both, suggested candidates to validate in your own design, not drop-in equivalents.
Parametrics // Side by side
Comparison table
| MPU-6000 (obsolete) | ICM-42688-P | BMI270 | MPU-6050 (obsolete) | |
|---|---|---|---|---|
| Vendor | TDK InvenSense | TDK InvenSense | Bosch Sensortec | TDK InvenSense |
| Lifecycle | Obsolete at TDK (status field, via archive 2025-11-15) | Active, in production | Active, in production | Obsolete / discontinued at TDK |
| Confidence | Confirmed (TDK field, archived) | Confirmed | Confirmed | Confirmed (TDK field) |
| Function | 6-axis (3-axis gyro + 3-axis accel) | 6-axis | 6-axis | 6-axis |
| Interface | SPI (to 20MHz) + I2C | SPI + I2C + I3C | SPI + I2C | I2C only |
| Package | QFN-24, 4×4×0.9mm | LGA-14, 2.5×3×0.91mm | LGA-14, 2.5×3×0.83mm | QFN-24, 4×4×0.9mm |
| Register map / driver identity | RM-MPU-6000A, WHO_AM_I 0x68 | Bank-switched map, different WHO_AM_I identity | Bosch map, own chip-ID scheme | RM-MPU-6000A (shared with MPU-6000) |
| Same-family note | subject | TDK's current 6-axis line | cross-vendor (Bosch) | I2C-only sibling, itself obsolete |
The load-bearing rows are the package and the register map / driver identity: every active cross changes both. The trap row is the MPU-6050, the only register-map match, and itself obsolete. Lifecycle, package and interface data is vendor-reported, not independently audited.
Next // The decision
What to do next
The path splits on one question, whether you stay on TDK tooling, and both paths end at the same gate.
Path A · staying on TDK
The current TDK 6-axis part, and the shortest path if your toolchain, sourcing and support relationships already sit with TDK.
- Re-layout the sensor block for LGA-14, 2.5×3mm
- New driver against the bank-switched register map
- Re-tune filtering and calibration to the new noise floor
Path B · leaving TDK
The cross-vendor path off TDK. The same board work as Path A, plus one step the MPU-6000 design has no equivalent for.
- Re-layout the sensor block for LGA-14, 2.5×3mm
- New driver against the Bosch register map
- ~8KB config upload in the boot sequence, every reset
Both paths
The target has to enumerate and stream in the existing firmware before the board is committed.
The register-map and driver rewrite is the gating validation, not the layout, prove it on a breakout before the re-layout is released.
The only register-map match, and itself obsolete at TDK, crossing to it moves the problem down the calendar instead of closing it.
What this doesn't say: this page reports each part's lifecycle status as read from the cited source on the verification date, and nothing beyond it. No date here is final; a status can change after publication, which is why the sources are listed below. No end use, program or system is named or implied.
FAQ // Frequently asked
Frequently asked questions
Is the MPU-6000 discontinued or still in production?
The MPU-6000 is discontinued, not in production. TDK's own Product Center lists the MPU-6000 Product Status as “Obsolete,” read from the archived capture of the page because the live page blocks automated fetches. Broker and last-time-buy stock still appears, but the maker status is end-of-life, so the reader-useful move is a planned migration rather than a stock hunt.
Can I replace the MPU-6000 with the ICM-42688-P without firmware or driver changes?
No, the ICM-42688-P requires firmware and driver changes, not a like-for-like swap. It uses a bank-switched register architecture with a different WHO_AM_I identity value from the MPU-6000, so an existing MPU-6000 driver will not enumerate or configure it, and the FIFO packet format and configuration registers differ. Flight-stack projects treat it as a separate driver, not a recompile of the MPU-6000 path.
Is the ICM-42688-P a drop-in for the MPU-6000 with the same footprint?
No, the ICM-42688-P is not a footprint-level drop-in. The MPU-6000 is a 24-pin QFN measuring 4×4×0.9mm and the ICM-42688-P is a 14-pin LGA measuring 2.5×3×0.91mm, so the package type, the pin count and the footprint all change and the board needs a re-layout at the sensor site. It is a suggested candidate to validate in your own design, not a drop-in.
What changes in the register map and FIFO going from the MPU-6000 to the ICM-42688-P?
The register map changes from the flat RM-MPU-6000A layout to a bank-switched architecture, and the FIFO packet format and configuration registers change with it. The MPU-6000 uses WHO_AM_I 0x68 on the RM-MPU-6000A map, while the ICM-42688-P answers with its own identity value on a banked map, so sensor init, sample-rate and filter configuration, and FIFO parsing all have to be rewritten for the new device.
Why does an ICM-42688-P show noise the MPU-6000 seemed to smooth out?
The ICM-42688-P exposes a different noise floor, filter set and output data rate than the MPU-6000, so a filter and calibration profile tuned for the MPU-6000 does not carry over. It specifies a 2.8 mdps/√Hz gyro noise density and its own programmable filter and ODR options, which means digital filtering and calibration in the host firmware are part of the migration, not just the register writes.
What is the successor to the MPU-6000?
The ICM-42688-P is the current TDK 6-axis MEMS IMU that migrations off the MPU-6000 most commonly target, and it is in production while the MPU-6000 is obsolete. It is a successor in the sense of the current same-vendor part, not a drop-in: the package, the register map and the driver all change, so it enters the design as a new part to qualify.
MPU-6000 vs MPU-6050, what is the difference, and is the MPU-6050 a safe cross?
The difference is the interface: the MPU-6000 supports both SPI and I2C, while the MPU-6050 is I2C-only, and the two share the RM-MPU-6000A register map, which is why the MPU-6050 looks like a like-for-like cross. It is not a safe migration target, because it is itself obsolete and discontinued at TDK, so crossing to it relocates the obsolescence rather than resolving it.
Sources // Public, primary
Sources
- TDK Product Center MPU-6000 status (Product Status: Obsolete), archived 2025-11-15
- MPU-6000 and MPU-6050 Product Specification (TDK, PS-MPU-6000A, PDF)
- MPU-6000 and MPU-6050 Register Map and Descriptions (RM-MPU-6000A, PDF)
- ICM-42688-P datasheet (TDK, DS-000347, PDF)
- ICM-42688-P product page (TDK InvenSense)
- Bosch BMI270 datasheet (Bosch Sensortec, PDF)
- MPU-6050 listing (DigiKey)
- ArduPilot: “Replacing MPU6000 with ICM20602 or ICM42688-P Without Firmware Changes”
Part of // Featured in
Related reading
Editorially independent and from public sources only; lifecycle, package, electrical and interface data is vendor-reported, not independently audited. Alternates are candidates to validate in your own design, confirm every detail with the manufacturer before committing.
About the author
Editorially independent and from public sources only; lifecycle, pin and rating data is vendor-reported, not independently audited. Alternates are candidates to validate in your own design. Confirm every detail with the manufacturer before committing.