Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
%DASHBOARD{ section="banner" | ||||||||
Line: 30 to 30 | ||||||||
If logging is activated (CFG_LOG_MSG defined) the logs are written to | ||||||||
Changed: | ||||||||
< < | 0:/var/log/messages | |||||||
> > | 0:/var/log/messages (not implemented yet) | |||||||
A cold restart is a CPU reset with RTC domain reset (power cycle, Power On Reset POR). A warm restart is a CPU reset without RTC domain reset. | ||||||||
Added: | ||||||||
> > | You can add following line to the /etc/rc.local
assert? [IF] assert# . .( Assertations since cold startup, last one: ) assert@ drop .assert [THEN]After ^C following message will appear after the greeting: 3 Assertations since cold startup, last one: ASSERT_CDC_SIGINT | |||||||
|
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
%DASHBOARD{ section="banner" | ||||||||
Line: 17 to 17 | ||||||||
Contents
| ||||||||
Changed: | ||||||||
< < | ||||||||
> > | ||||||||
How to use | ||||||||
Line: 36 to 36 | ||||||||
Changed: | ||||||||
< < | ||||||||
> > | ||||||||
Implementation |
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
%DASHBOARD{ section="banner" | ||||||||
Line: 32 to 32 | ||||||||
If logging is activated (CFG_LOG_MSG defined) the logs are written to
0:/var/log/messages | ||||||||
Changed: | ||||||||
< < | A cold restart is a CPU reset with RTC domain reset (power cycle). A warm restart is a CPU reset without RTC domain reset. | |||||||
> > | A cold restart is a CPU reset with RTC domain reset (power cycle, Power On Reset POR). A warm restart is a CPU reset without RTC domain reset. | |||||||
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
%DASHBOARD{ section="banner" | ||||||||
Line: 50 to 50 | ||||||||
Added: | ||||||||
> > |
Hardfaults/* activate divide by zero trap (usage fault) */ SCB->CCR |= SCB_CCR_DIV_0_TRP_Msk; /* enable Usage-/Bus-/MPU Fault */ SCB->SHCSR |= SCB_SHCSR_USGFAULTENA_Msk | SCB_SHCSR_BUSFAULTENA_Msk | SCB_SHCSR_MEMFAULTENA_Msk;https://interrupt.memfault.com/blog/cortex-m-fault-debug | |||||||
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
%DASHBOARD{ section="banner" | ||||||||
Line: 25 to 25 | ||||||||
assert ( flag n u -- ) abort if flag is false and assertion is activated, log n and u after restart assert? ( -- flag ) Was there an assert? assert# ( -- u ) How many asserts occurred since cold startup? | ||||||||
Changed: | ||||||||
< < | assert@ ( -- n u ) Assert number and parameter e.g. address where the assert occurred .assert ( n u -- ) Print assert message | |||||||
> > | assert@ ( -- u1 u2 ) Assert number u1 and parameter u2 e.g. address where the assert occurred .assert ( u -- ) Print assert message | |||||||
If logging is activated (CFG_LOG_MSG defined) the logs are written to |
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
%DASHBOARD{ section="banner" | ||||||||
Line: 32 to 32 | ||||||||
If logging is activated (CFG_LOG_MSG defined) the logs are written to
0:/var/log/messages | ||||||||
Changed: | ||||||||
< < | A cold restart is a CPU reset with RTC domain reset. A warm restart is a CPU reset without RTC domain reset. | |||||||
> > | A cold restart is a CPU reset with RTC domain reset (power cycle). A warm restart is a CPU reset without RTC domain reset. | |||||||
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
%DASHBOARD{ section="banner" | ||||||||
Line: 9 to 9 | ||||||||
Intro
For severe failures e.g. stack overflow the only way to recover for embedded systems is a reset (warm restart, abort). Other asserts (unknown events) can be ignored because they do not have fatal consequences. But for debugging during the development cycle, all asserts should be observed. Therefore Mecrisp-Cube has two types of asserts: fatal asserts and non-fatal asserts. The non-fatal asserts can be ignored in production systems. | ||||||||
Changed: | ||||||||
< < | After a fatal assert nothing can be considered as working, even the return from a subroutine can be not possible anymore. Therefore the file system cannot be used and the log can only be written after a restart. | |||||||
> > | After a fatal assert nothing can be considered as working, even the return from a subroutine can be not possible anymore. Therefore the file system cannot be used and the log can only be written after a warm restart. | |||||||
RTC registers are used for accounting the asserts. Those registers are not affected by the reset. After the restart the registers are evaluated and the information is written to the log. | ||||||||
Line: 24 to 24 | ||||||||
fatalassert ( flag n u -- ) abort if flag is false, log n and u after restart assert ( flag n u -- ) abort if flag is false and assertion is activated, log n and u after restart assert? ( -- flag ) Was there an assert? | ||||||||
Changed: | ||||||||
< < | assert# ( -- u ) How many aseerts occured since cold startup? assert@ ( -- n u ) Assert number and parameter e.g. address where the assert occured | |||||||
> > | assert# ( -- u ) How many asserts occurred since cold startup? assert@ ( -- n u ) Assert number and parameter e.g. address where the assert occurred | |||||||
.assert ( n u -- ) Print assert message | ||||||||
Changed: | ||||||||
< < | If logging is activated the logs are written to
/var/log/messages | |||||||
> > | If logging is activated (CFG_LOG_MSG defined) the logs are written to
0:/var/log/messages
A cold restart is a CPU reset with RTC domain reset. A warm restart is a CPU reset without RTC domain reset. | |||||||
Deleted: | ||||||||
< < | /var/log/messages | |||||||
https://en.wikipedia.org/wiki/Assertion_(software_development) |
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
%DASHBOARD{ section="banner" | ||||||||
Line: 21 to 21 | ||||||||
How to use | ||||||||
Changed: | ||||||||
< < | fatalassert ( flag n -- ) abort if flag is false, log n after restart assert ( flag n -- ) abort if flag is false and assertion is activated, log n after restart | |||||||
> > | fatalassert ( flag n u -- ) abort if flag is false, log n and u after restart assert ( flag n u -- ) abort if flag is false and assertion is activated, log n and u after restart | |||||||
assert? ( -- flag ) Was there an assert? assert# ( -- u ) How many aseerts occured since cold startup? | ||||||||
Changed: | ||||||||
< < | assert@ ( -- n ) Assert number .assert ( n -- ) Print assert message | |||||||
> > | assert@ ( -- n u ) Assert number and parameter e.g. address where the assert occured .assert ( n u -- ) Print assert message | |||||||
If logging is activated the logs are written to | ||||||||
Line: 40 to 40 | ||||||||
/var/log/messages https://en.wikipedia.org/wiki/Assertion_(software_development) | ||||||||
Changed: | ||||||||
< < | ||||||||
> > | ||||||||
During development cycle, the programmer will typically run the program with assertions enabled. When an assertion failure occurs, the programmer is immediately notified of the problem. Many assertion implementations will also halt the program's execution: this is useful, since if the program continued to run after an assertion violation occurred, it might corrupt its state and make the cause of the problem more difficult to locate. Using the information provided by the assertion failure (such as the location of the failure and perhaps a stack trace, or even the full program state if the environment supports core dumps or if the program is running in a debugger), the programmer can usually fix the problem. Thus assertions provide a very powerful tool in debugging. When a program is deployed to production, assertions are typically turned off, to avoid any overhead or side effects they may have. | ||||||||
Added: | ||||||||
> > | ||||||||
Line: 55 to 56 | ||||||||
-- Peter Schmid - 2021-12-25
This work by Peter Schmid is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. | ||||||||
Added: | ||||||||
> > |
|
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
%DASHBOARD{ section="banner" | ||||||||
Line: 21 to 21 | ||||||||
How to use | ||||||||
Changed: | ||||||||
< < | assert ( flag n -- ) abort if flag is false, log n after restart fatalassert ( flag n -- ) abort if flag is false and assertion is activated, log n after restart | |||||||
> > | fatalassert ( flag n -- ) abort if flag is false, log n after restart assert ( flag n -- ) abort if flag is false and assertion is activated, log n after restart | |||||||
assert? ( -- flag ) Was there an assert? assert# ( -- u ) How many aseerts occured since cold startup? assert@ ( -- n ) Assert number | ||||||||
Added: | ||||||||
> > | .assert ( n -- ) Print assert message | |||||||
Added: | ||||||||
> > | If logging is activated the logs are written to
/var/log/messages | |||||||
| ||||||||
Line: 36 to 40 | ||||||||
/var/log/messages https://en.wikipedia.org/wiki/Assertion_(software_development) | ||||||||
Added: | ||||||||
> > | ||||||||
During development cycle, the programmer will typically run the program with assertions enabled. When an assertion failure occurs, the programmer is immediately notified of the problem. Many assertion implementations will also halt the program's execution: this is useful, since if the program continued to run after an assertion violation occurred, it might corrupt its state and make the cause of the problem more difficult to locate. Using the information provided by the assertion failure (such as the location of the failure and perhaps a stack trace, or even the full program state if the environment supports core dumps or if the program is running in a debugger), the programmer can usually fix the problem. Thus assertions provide a very powerful tool in debugging. When a program is deployed to production, assertions are typically turned off, to avoid any overhead or side effects they may have. | ||||||||
Added: | ||||||||
> > | ||||||||
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
Added: | ||||||||
> > |
Assertation and Logging
Intro
For severe failures e.g. stack overflow the only way to recover for embedded systems is a reset (warm restart, abort). Other asserts (unknown events) can be ignored because they do not have fatal consequences. But for debugging during the development cycle, all asserts should be observed. Therefore Mecrisp-Cube has two types of asserts: fatal asserts and non-fatal asserts. The non-fatal asserts can be ignored in production systems.
After a fatal assert nothing can be considered as working, even the return from a subroutine can be not possible anymore. Therefore the file system cannot be used and the log can only be written after a restart.
RTC registers are used for accounting the asserts. Those registers are not affected by the reset. After the restart the registers are evaluated and the information is written to the log.
Contents
How to useassert ( flag n -- ) abort if flag is false, log n after restart fatalassert ( flag n -- ) abort if flag is false and assertion is activated, log n after restart assert? ( -- flag ) Was there an assert? assert# ( -- u ) How many aseerts occured since cold startup? assert@ ( -- n ) Assert number Implementation/var/log/messages https://en.wikipedia.org/wiki/Assertion_(software_development) During development cycle, the programmer will typically run the program with assertions enabled. When an assertion failure occurs, the programmer is immediately notified of the problem. Many assertion implementations will also halt the program's execution: this is useful, since if the program continued to run after an assertion violation occurred, it might corrupt its state and make the cause of the problem more difficult to locate. Using the information provided by the assertion failure (such as the location of the failure and perhaps a stack trace, or even the full program state if the environment supports core dumps or if the program is running in a debugger), the programmer can usually fix the problem. Thus assertions provide a very powerful tool in debugging. When a program is deployed to production, assertions are typically turned off, to avoid any overhead or side effects they may have.This work by Peter Schmid is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. |