Once again, the ST Community came together in November to show that the ST ecosystem is always bigger than the sum of its parts. For those that may not be familiar with this platform, it is a special place where academia, engineers, enthusiasts, and ST employees meet to share ideas and projects, collaborating to solve problems or explore alternative approaches to challenges. It’s open to all and is full of content and contributions found nowhere else. The community is also unique because of its complementary relationship with the Life.Augmented blog. Beyond these monthly reports that highlight the most significant contributions in the community, both websites build on one another.
For instance, as early as last September, community members were asking when the STM32L4+ family of products would launch and what to expect. Then, on November 14, we published an introductory post to celebrate the arrival of the new MCUs that run at a record 120 MHz in smartwatches and wearables, among many other embedded systems. Once the members learned of the launch, conversations in the community drilled deeper into some of the new features, such as the optimizations for round displays. Finally, Szymon Panecki, an ST employee, directed the community members to a series of online training sessions teaching how to better use the STM32L4+. This synergy is what makes the ST ecosystem special, and to continue this back and forth with the community, we are thrilled to look at three community posts that got a lot of traction last month.
When the Community Bypasses the Unknown
Majerle Tilen, a Field Application Engineer and an essential contributor to the community, started November’s most popular thread. In it, he details a way to take advantage of the DMA (Direct Memory Access) feature of a microcontroller (MCU) to offload the CPU, even if developers don’t know the size of the data transfer from the UART peripheral. Indeed, to take advantage of the DMA, engineers must determine the transfer’s exact number of bytes before it takes place. Unfortunately, this isn’t always possible. The alternative would be to use the RXNE (Receive Not Empty) feature of the UART interface, but the CPU must then handle every byte, which can take a lot of resources when dealing with high data rates.
Majerle showed how a feature called IDLE line detection can solve this conundrum. In other words, if developers know they will receive between 10 and 20 bytes, they can write a code provisioning for 20 bytes, and start obtaining data. As soon as the RX line detects the system is no longer getting data, it will throw an interrupt, which can trigger an event that will shut down the DMA stream and signal that the transmission is complete. He even wrote an example code that can be tested on NUCLEO-F401RE and NUCLEO-F411RE boards. The reception from the community has been tremendous, many members thanking him for this brilliant strategy, and we can’t wait for more enthusiasts to try it out.
- Efficiently use DMA with UART RX on STM32
Beyond The Looking Glass
Sometimes, a problem may not be where we think it is. This is the lesson we all learned from one of the most active community posts last month. While using the STM32F722ZE MCU of his NUCLEO board, Ian Reishauer couldn’t understand why the system didn’t reach a frequency of more than 50 MHz. After looking at the generated assembler code and analyzing the problem from all possible angles, Jan Waclawek wondered if the data from the probe wasn’t the real issue. It turned out the oscilloscope wasn’t keeping up, ultimately giving false data. Once Ian switched to a more appropriate tool, he saw that the MCU was indeed running at a higher frequency. It’s the kind of situation that can happen to anyone and a great example of how the minds of the ST community come together to look at a problem differently and find solutions in unexpected places.
- Toggling a GPIO pin at 50 + MHz
Stay Protected
The community can also be a great tool to take advantage of specific features that aren’t always obvious. For instance, a post that got a lot of traction in November looked at using the Memory Protection system included in MCUs from ST. In a nutshell, it’s possible to prevent overwriting certain parts of the memory to protect an application from an external attack or potential errors. Unfortunately, despite his best efforts, Hussain Mozahir couldn’t get the feature to work. In other words, his program would overwrite the supposedly protected memory locations instead of throwing an exception. As he asked for help, many community members looked at his source code and offered different solutions to activate the memory protection. Today, anyone can look at this discussion and draw inspiration from the various solutions to quickly benefit from this feature.
- Why is MPU not generating any fault?
To join the ST Community, help others, find answers, or meet like-minded enthusiasts that also use ST products, please visit community.st.com.
