Skip to content

Should ITM write functions check if a debugger is connected like CMSIS ITM_SendChar ? #74

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
jothan opened this issue Jan 12, 2018 · 4 comments

Comments

@jothan
Copy link

jothan commented Jan 12, 2018

I am currently unable to run my application standalone when a debugger is not present. I am suspecting that it is because the TPIU and the ITM port are not enabled by my code. Removing traces fixes my issue.

Would it be a good idea to check if tracing is enabled like ITM_SendChar ?

https://github.com/ARM-software/CMSIS/blob/6891719834ac6ca2a79e8ded00620faffae10ae8/CMSIS/Include/core_cm3.h#L1698

If so, I would like to submit a pull request to short circuit write_all if tracing is not enabled.

@japaric
Copy link
Member

japaric commented Mar 10, 2018

Would it be a good idea to check if tracing is enabled like ITM_SendChar ?

I would prefer not to slow down the ITM logging functionality as I use it log data at high data rates so low overhead is a must.

I am suspecting that it is because the TPIU and the ITM port are not enabled by my code

There's ITM initialization code in #82 but it requires unsafe code. That issue is about making the initialization code safe; I would push for that instead of this issue.

@nickray
Copy link

nickray commented Mar 16, 2019

Just ran into this issue too, agree that the write functions should not do a non-zero cost check. But the documentation might want to mention that they never return if the ITM is not enabled as in #82.

@jonas-hagen
Copy link

jonas-hagen commented Jun 22, 2019

I experienced this issue as well, took me a while to find out whats going wrong. Because it only happens if the debugger is not connected, it is a bit hard to debug.

What about having the check done in the iwrite macros just to keep beginners (like me) away from this issue?

@bcantrill
Copy link

bcantrill commented Jun 9, 2020

Just came across this issue; assuming this issue is being seen on ARMv8-M parts (vs. ARMv7-M), it seems quite likely that it is in fact a duplicate of #219.

bors bot added a commit that referenced this issue Jun 10, 2020
227: ITM: don't test reserved bits in is_fifo_ready r=adamgreig a=bcantrill

This is a follow up to the discussion in #219, capturing the conclusion by @cbiffle  and @adamgreig there: to indicate that the ITM FIFO is ready on FIFOREADY (only) on ARMv7-M (only) and to indicate the FIFI is ready on *either* FIFOREADY *or* DISABLED on ARMv8-M. ITM has been tested and verified on an ARMv7-M CPU (an STM32F407, a Cortex-M4) and an ARMv8-M CPU (an LPC55S69, a Cortex-M33).

Without this fix, any use of ITM will hang on ARMv8-M -- which may in fact be the root cause of #74...

Co-authored-by: Cliff L. Biffle <[email protected]>
adamgreig pushed a commit that referenced this issue Jan 12, 2022
306: fix #74 r=jonas-schievink a=spookyvision

special-cased linker section names to satisfy macos linker constraints

Co-authored-by: Anatol Ulrich <[email protected]>
@bors bors bot closed this as completed in 95b2837 Jan 23, 2022
@adamgreig adamgreig reopened this Jan 23, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants