What can a System-on-Module do for engineers? We sat down with PHYTEC, an ST Authorized Partner, to understand this question through the lens of its STM32MPx SoMs. It is one of the first questions engineers ask, and the answer often shapes a project in significant ways. Since a system-on-module includes memory, the power supply, and the processor, among other things, using one strongly influences the hardware specifications of the final release. Moreover, a SoM also comes with a software ecosystem that can have a big impact on development operations.
One thing is clear: the benefits of this modular approach can reverberate for a decade or more and can extend across a 10- to 15-year lifecycle, as the component lifecycle management is offloaded to the SoM maker. Hence, let’s explore the world of SoMs through PHYTEC as we outline the three tips to help engineering teams get started.
Tip #1. Use a development board to discover what the final design will actually need
Don’t settle on hardware too early
It’s easy to get carried away trying to create a custom board based on the ideas that motivated the creation of the product in the first place. In fact, it’s how many engineers have learned their trade. Open Altium, KiCAD, or Eagle if nostalgia sets in, and get cracking. The problem is that it forces designers to spend time they don’t have tackling challenges already solved by others like PHYTEC, who already qualified essential circuitry, including the HDI PCB stackup.
All the while, the same team is unsure which features will make it into the finished product, when that’s what they should be working on. For example, in a computer vision application, a team may be unsure what image sensor can meet their frame rate and environment conditions. Experimenting with different sensors or finding ways to lower the bill of materials is a better use of time than tuning RAM.
Don’t overlook software effort
The lesson is simple: don’t change what works, because every hardware modification becomes a software task. Consequently, teams should start with a development board that exposes as many underlying STM32 MPU features as possible, and copy its implementation. It’s for this reason that PHYTEC pairs the phyCORE-STM32MP13x SoM with the phyBOARD-Segin development board, the phyCORE-STM32MP15x SoM with the phyBOARD-Sargas development board, or the phyFLEX-STM32MP2x SoM with the phyBOARD-Libra development board. When creating a custom board, PHYTEC recommends copying its implementation, even for basic interfaces like the UART for the serial console, I2C, SPI, and GPIO. For example, using USART0/UART0 is one less task for the software team to implement.
Don’t stop experimenting
Another advantage of development boards is that they favor experimentation with different configurations. For example, the phyCORE-STM32MP15x uses a board-to-board connector, making it easy to move the SoM between boards. PHYTEC also offers many off-the-shelf configurations, allowing teams to swap modules with different memory capacities.
The phyFLEX-STM32MP2x takes a similar approach with its future-proof solder core (FPSC), which requires soldering but uses a standardized pinout across PHYTEC SoMs, meaning engineers can move the SoM without redesigning the carrier board and can also drop in a future STM32 MPU as an upgrade. Put simply, working with boards from PHYTEC lets teams take advantage of many STM32 MPUs, allowing them to experiment with different memory configurations, CPU cores, and more, which aren’t really possible when relying only on a simulator or spec sheet.
Tip #2. Make a working prototype that another engineer can easily rebuild
Don’t forget to evaluate the software ecosystem
Engineers know too well that collaborative work is very different from single-handedly coming up with a proof-of-concept in a lab. When others on a team must recreate a boot image, a configuration file, load the same drivers and middleware, or even recreate a whole application, things can get complex fast. That is why PHYTEC provides a Yocto-based Linux BSP and documentation. Developers can still use STM32CubeMX and ST firmware packages to build on the experience they have gained with our tools while also benefiting from a software ecosystem with a strong community. In fact, PHYTEC has STM32CubeMX project files available with the pinout and clock tree configured.
Don’t dismiss code isolation
Once teams start working on custom implementations, PHYTEC recommends creating a Yocto meta layer on top of the Board Support Package to clearly separate customer code from the ST/PHYTEC lower levels. PHYTEC even provides a two-day hands-on Yocto training course to help developers make the most of it, regardless of experience level. Both ST and PHYTEC also mainline a Linux kernel as the foundation of our BSP to leverage the open-source community, improve support operations, and increase accessibility by ensuring more teams can adopt our technologies. In a nutshell, choosing the right SoM means choosing an ecosystem that benefits more than just one company, one lab, or one project.
Tip #3. Rehearse what happens after release or perform a pre-mortem
Don’t let overconfidence ruin hard work
Based on an article published in the Harvard Business Review in 2007, a pre-mortem is a popular managerial strategy in which a team imagines the reasons a project or product could fail once it is in the field. Too often, a company can be overconfident and lack the imagination to anticipate common worst-case scenarios, like a security breach or a failed over-the-air update that bricks their system. And too often, engineering teams underestimate the importance of the development ecosystem once the product leaves the lab. However, security audits, key changes, and the ability to debug systems after commercial release all depend on the hardware and software ecosystem.
Don’t forget to plan for the worst
PHYTEC has been in the industry for 40 years, which is why they don’t only offer SoMs but also services leveraging their expertise, including free schematic reviews, security consultations, development service contracts, and end-to-end production solutions. One common piece of advice is to test worst-case scenarios extensively before shipping. For example, a failed over-the-air update that bricks a fleet is a classic pre-mortem. PHYTEC has many examples and application notes to guide users through OTA implementations and testing in an isolated environment before deployment. Another common failure is a component change that breaks a working design. PHYTEC’s change-notification process includes qualification, documentation, and sample programs to verify a change before ordering large batches.
Don’t underestimate best security practices
Security audits and key changes happen after release, so a platform needs to support them from day one. On one side, STM32 MPUs can target SESIP Level 3 certifications for teams that need objective security guarantees. On the other, PHYTEC prepares Secure Boot, handles cryptographic key management, and supports JTAG deactivation to close the debugger ports on shipped units. PHYTEC even offers services to address obsolescence and future-proof designs by anticipating regulatory requirements and leveraging what ST offers, from our cryptocore to our functional safety packages.
- Learn more about PHYTEC
- Check out the STM32 microprocessors
For more information visit: https://blog.st.com/phytec/.
