Product Lifecycle Issues with System-on-Modules

Home/System on Module/Product Lifecycle Issues with System-on-Modules

We have now been supplying modules for over 20 years, and are currently offering a longevity guarantee of 10 years for new design ins. Very nice, but what are the implications and challenges from the user perspective of using a module over a long period?

Despite our best efforts (and the level of effort that goes into scrutinizing the BOM from a longevity point of view is considerable), and that of our suppliers, small changes are inevitable over a 10 year lifetime. Flash memory die shrinks, processor steppings and other changes are inevitable. But the plan is always to deal with these, ideally without any software change, or worst case with a bootloader or even a BSP modification. The bootloader and BSP is designed with this in mind.

Similarly, if you want the advantages of mainline Linux, so having the latest version of Linux to work with during your development, the other side of that coin is that the version of Linux will continue to roll after your development is complete, and so again this is taken care of in the bootloader, so the standard bootloader which is installed in the delivered modules will also not remain the same.

With all this going on, you should be largely unaffected during your product’s lifetime, providing you remember a couple of things:

  1. Always program the bootloader as well as your application. This is pretty obvious. But sometimes we see customers, especially those who outsourced their development and are not familiar with the production programming process, installing the application but failing to overwrite the necessarily ever-changing bootloader that comes with the module. This may work across some bootloader version changes, but eventually will break.
  2. Don’t modify the bootloader during development. Sometimes, if you know what you’re doing, it’s really easy to effect a change in your target by means of a bootloader modification, but other than in the last resort this is a bad idea. Instead, if you really can’t do what you need from the application, ask us to accommodate your needs in the next bootloader update. If you modify the bootloader, and later we have to make changes to accommodate a hardware change, you will have to modify the new bootloader in line with your original modifications. If 5 years have gone by, you may not remember what you did, or the person who made the modifications may have moved on.
  3. Look out for PCNs. One service we provide to our production module customers is to keep them informed of any Product Change Notice, and to help each customer to make and checks or changes needed if a PCN impacts them. Make sure we have your correct details, and log into the “Prodblog” system.

Remember, you can call or email us if you have any concerns. Our business depends on our customers’ success, so we are always ready to help.

By | 2017-05-19T13:12:00+00:00 March 5th, 2015|System on Module|0 Comments

Leave A Comment