Project Background
During my CATARC internship, I worked on STM32WLE development for an IoT communication control module. The module was not a single peripheral experiment. It involved I2C, UART, SPI, RS485, one-wire communication, RTC, FatFS, and multi-channel sensor acquisition.
The risk in this kind of project is not whether one interface can be brought up. The risk appears when many interfaces are developed together and driver code, task logic, and business code start to mix. If every new module copies its own initialization, read/write flow, and exception handling, the code becomes harder to maintain and interface faults become hidden behind application-level symptoms.
Core Problem
The core problem was that communication errors were difficult to identify from symptoms alone. The application layer might only show abnormal sensor values or frame errors, while the root cause could be interface-level mismatch, unstable bus timing, incorrect driver call order, file-write blocking, or timestamp handling.
Without clear driver boundaries, debugging becomes guessing inside a large block of business logic. I narrowed the objective to two points: make different interface drivers reusable, and make each communication path independently verifiable.
My Approach
I reorganized the code using HAL, BSP, and App layers. The HAL layer kept chip-library capabilities. The BSP layer wrapped concrete peripherals and board differences. The App layer only organized acquisition, storage, and business flow. This meant the application did not need to know register details or interface initialization details.
For FatFS and RTC, I placed them in the structured data path. Sensor data was written with synchronized timestamps so later analysis could trace the sampling moment. For the GX30H05 multi-channel acquisition driver, I separated acquisition, parsing, and exception judgment so each step could be observed independently.
Debugging and Verification
The clearest debugging case was one-wire communication errors. The application layer only showed unstable data, which was not enough to prove whether the problem came from software or the hardware path. I used a logic analyzer and an oscilloscope to observe waveforms and align software timing with real voltage changes.
This process turned “it looks like a driver issue” into a verifiable conclusion. If the interface level was mismatched, continuing to change parsing code was meaningless. Only after the physical path and timing were confirmed could software retries, checks, and exception branches be evaluated properly.
Final Result
After the refactor, driver boundaries and application responsibilities became clearer, and multi-interface code reuse improved by more than 50%. Debugging notes and compatibility recommendations were included in the team interface standard, reducing later integration cost for similar modules.
The value was not only that one function worked. The project also preserved driver abstraction, path verification, and problem-location methods that could be reused in later embedded work.
Review Takeaways
Embedded communication debugging cannot stay inside code only. Many symptoms appear at the application layer, while the cause is often at the interface, timing, or hardware-connection layer. My practical rule is to split software boundaries first, verify the real path with instruments, and then return to code for exception handling and reuse.
This is also how I write technical reviews: not just “I implemented a driver,” but why the boundary was drawn, how the issue was verified, and whether the result can be reused by the next project.