Introduction

The Renesas RX family has been in production for many years, and many products built on it now need a change, whether to a higher-performance part, a part with more memory or a part with more connectivity. Because the family shares a common architecture, a common toolchain and much of its middleware, a migration is usually a matter of mapping the peripherals rather than rewriting the application. This application note explains how to plan and execute an RX migration.

Why the RX Family Migrates Well

The RX family's value in a long-lifecycle product is that it provides a migration path within one architecture. The core and the architecture stay the same across the family, and the toolchain and much of the middleware are shared, so code and drivers move between devices with modest change. That continuity protects the software investment and reduces the risk of a product refresh, which is why the family remains widely used in industrial, networking and office equipment.

Pin Compatibility

Related RX devices often share a pin assignment, so a migration can sometimes be a drop-in replacement with a firmware update. Where the pinout differs, the changes are usually confined to the pins that the new device adds or moves, and the migration note documents them.

Planning the Migration

Begin by comparing the two devices: the core frequency, the memory, the peripherals and the package. Identify the peripherals the application uses and confirm that the new device provides them, and note any differences in the registers or the timing. Then review the middleware and the drivers, because the shared components can usually be reused with a configuration change rather than a rewrite.

Peripheral Differences

The peripherals are where most migrations need attention, because a new device may add, remove or change a peripheral. Map each peripheral the application uses to its counterpart on the new device, and confirm the register-level differences before porting the code.

Power and Clock Review

A migration is a good time to review the power and the clock design, because the new device may have different requirements. Confirm the rails and the regulator against the new device, and check the clock tree and the oscillators. A dual regulator such as the ISL78208 covers the several rails a controller needs, and a programmable clock generator can provide the clocks the new device requires.

Thermal and Package

If the new device has a different package or a higher frequency, the thermal design may need a review. Confirm the package fits the board and that the thermal path is adequate for the new dissipation, and validate the design at the worst-case temperature.

Validation

After the migration, validate the design as if it were new: check the peripherals, the interfaces, the timing and the power, and run the application through its functions. A migration is a change, so it deserves the same validation as a new design. BeiLuo's FAE team can support the migration and supply samples for validation.

Conclusion

The RX family's shared architecture and middleware make a migration practical, and the main work is mapping the peripherals and reviewing the power and clock design. Plan the migration early, reuse the shared components, and validate the result as if it were new; do those things and the product refresh is predictable.