An AVR migration should begin with the exact device's lifecycle evidence and the product's technical requirements. A notice affecting one ordering code does not establish that the AVR family is discontinued. Separate the reason for migration from the engineering work needed to move the design onto a supported candidate.
Choose candidates using the functions in service
Microchip's AN3731 covers migration from megaAVR to AVR Dx, comparing similarities and differences between the families. Its guidance is a starting point for porting work rather than a declaration that two devices are interchangeable.
List the peripherals actually used, their pin assignments and any timing constraints. Include program memory, RAM, persistent storage, analog references, clock sources and supply conditions. Identify application code that accesses registers directly or depends on interrupt timing. Those details often determine the migration effort more accurately than flash capacity or a shared architecture name.
Plan board, firmware and tool changes together
Compare package drawings and pin configurations against the existing schematic. Review reset, boot and programming connections, and identify any fixture changes needed for the candidate's supported programming interface. Check that production programmers and debugging tools support the exact target device.
Create a firmware porting list for startup, clock configuration, peripheral initialization, interrupts and nonvolatile storage. Keep hardware access isolated where practical so functional application tests can be reused. Review compiler settings and libraries, and confirm that generated timing still satisfies interfaces that depend on precise pulse widths or baud rates.
Preserve product behavior through qualification
Before porting, capture baseline measurements from the existing product: startup sequence, communication responses, analog readings, power modes and recovery from faults. Define which behavior must remain identical and which improvements are allowed. Include stored calibration and field configuration in the migration plan.
Test the new implementation across the required supply and temperature range. Repeat production programming and end-of-line testing with the updated fixture and software. Approve the hardware revision, firmware build and programming configuration as a complete release. Keep remaining legacy stock identified separately so production cannot mix devices that need different images or procedures.
Frequently asked questions
Does an AVR lifecycle issue require moving to another architecture?
Not necessarily. Compare suitable current AVR devices and other architectures against the application's requirements and total migration effort.
Can a successful compile establish firmware compatibility?
No. Register behavior, clocks, interrupts, analog performance and production programming must be verified on the target hardware.
Request AVR sourcing or migration candidates with the original code, required peripherals and allowed board changes. Stock, price and lead time are confirmed in the quotation.