diff --git a/src/triceDefaultConfig.h b/src/triceDefaultConfig.h
index 3539898f5..53d25b58c 100644
--- a/src/triceDefaultConfig.h
+++ b/src/triceDefaultConfig.h
@@ -102,13 +102,13 @@ extern "C" {
 #ifndef TRICE_PROTECT
 //! The TRICE_PROTECT switch is only relevant for the deferred trice modes TRICE_DOUBLE_BUFFER and TRICE_RING_BUFFER.
 //! The trice library works well, when less data are produced in the average than transmittable and when in the double buffer case the TriceTransfer
-//! function is called before too much data in a half buffer according to a good configuration. If that is guarantied you do not need to enable TRICE_PROTECT.
+//! function is called, before too much data in a half buffer according to a good configuration. If that is guarantied you do not need to enable TRICE_PROTECT.
 //! If because of an potential error this is not guarantied, you should enable TRICE_PROTECT. This slows down the TRICE macros a bit, but makes buffer overflows impossible.
 //! A ring buffer cannot overflow in a first assumption, because old, not yet transmitted, trices are overwritten by newer ones.
 //! But that can happen only to parts of trices. The ring buffer read out function relies on consistent data. If it gets data garbage, wrong values
 //! for the trice lengths are possible and buffer overruns not avoidable. When enabling TRICE_PROTECT, new trices are only written into the deferred buffer,
 //! if there is enough space. That guaranties data consistency. Because a suppressed trice cannot cause a cycle error, there is TriceOverflowCount as diagnostic value.
-//! Long story short: If you sure tot to produce tot too much data, than set TRICE_PROTECT to 0 and get a bit more speed.
+//! Long story short: If you sure, not to produce too much data, than set TRICE_PROTECT to 0 and get a bit more speed.
 #define TRICE_PROTECT 1
 #endif