- #Segger embedded studio save log to csv serial#
- #Segger embedded studio save log to csv software#
- #Segger embedded studio save log to csv code#
- #Segger embedded studio save log to csv Bluetooth#
By default, SEGGER Embedded Studio will read the fileĪll tools are wrapped in a tools element: ⁞ The SEGGER Embedded Studio application will read the tool configuration file when it
Syntax for its simple construction and parsing. I have to say that I discovered new defects that even customers never noticed before.SEGGER Embedded Studio external-tool configuration files are structured using XML I can share my dashboards to my workmates and track user bugs more easily by adding some filters and displaying beautiful graphs 🤩. These tools are pretty handy and entirely fill the need I have. For your information, all the warnings are sent to Big Query and then linked to Data Studio. Every day, I can now check which errors occurred the most along with the number of people affected, running on a specific firmware version etc.
#Segger embedded studio save log to csv code#
The next step has been to set up a dashboard to be able to track code quality over time.
It’s already very useful, but as the amount of information got larger and larger, I quickly realized that I needed to make tools around that giant table.
A few days after the feature has been released, I have many entries of error codes and descriptions into the database. This feature is really useful to see which critical issues are actually happening on released firmware. Using the RAM region, I can also track any HardFault error or watchdog timeout and send the Program Counter or the task being executed when the fatal error is happening 🐛. At reset, I can now send the error to the remote peer once connected. I use that region to store failed assertion values (file hash, line and code). The content is kept across resets so I can have several variables stored, and a CRC to ensure data integrity. So I implemented a RAM region that is not init at startup. Here is an example from the Flash driver, which is not able to write chunks bigger than FLASH_PAGE_SIZE (512), line 123: #define FLASH_PAGE_SIZE 256 void flash_write_page(uint32_t addr, uint8_t* data, uint32_t length) Īnother concern I had to deal with is that on failing assertion, the device resets, meaning the warning message is not sent.
#Segger embedded studio save log to csv serial#
When an assertion fails while running in the “debug” configuration, I have a handler that can log the file, line and error code to the serial output or RTT (see Segger). My code is populated with assertions that are verified here and there (hopefully yours too). So now that I am able to send warnings, I have to figure out what to send. Then, the Equisense app send that data to our database, along with the user email address, phone model, firmware version, etc, for further analysis… (keep reading 😉) Best use case: catching failed assertions For example, here are some error codes about some storage issues: #define WARN_STORAGE_CORRUPT ( WARN_STORAGE + 0) #define WARN_STORAGE_LOW ( WARN_STORAGE + 1) #define WARN_STORAGE_FAILURE ( WARN_STORAGE + 2)Īlong with the WARN_STORAGE_CORRUPT code, I could pass the type of the corrupted data or the page number affected by that bug.Īll warnings are sent to the remote as they happen through Bluetooth, or queued for transmission afterwards if it’s not connected. Then, a human-readable string gives more information about the error: origin, causes or whatever you would expect to understand the issue. With that in mind, I implemented a lightweight solution: each log have to be contained in 18 bytes maximum (BLE 4.0 has a restriction of 20 usable bytes in each packet). So imagine having to keep many human-readable sentences into the Firmware, to be sent wirelessly to the remote peer: that’s way too heavy.
#Segger embedded studio save log to csv Bluetooth#
Plus, communication throughput needed to pass all the information quickly, is eventually limited, using Bluetooth Low Energy for example. Logging any type of data on an embedded device is obviously harder than a personal computer as there isn’t much space to store the whole program on the target. Keep it lightįirst, to catch bugs in production, I wanted to log usage data. The few solutions I’m sharing in this post made me realize how many flaws were on trackers in production… I now regret not to have implemented such ideas before. Firmware is hard to debug in its real environment and developers have to admit they tend to overlook the issues occurring on the spot for the sake of convenience 🙄.
#Segger embedded studio save log to csv software#
You can test your software as much as you want, the product you are working on may work great at the office but will undoubtedly get plenty of unexpected issues in the hands of end users.
0 kommentar(er)
