Timer-Queue does not seem to execute tasks when debugger is not attached #123
Comments
|
Looks similar to rust-embedded/cortex-m#111 |
|
Seems to be already called in RTFM, but not the access magic described on the stack overflow thread. |
|
Possibly relevant (in case different vendors implement this functionality in different ways) - the specific chip in question here is the Nordic nRF52832, an |
|
Confirm, on my nRF52-DK (PCA10040) RTFM-based blinky example doesn't work without debugger attached. EDIT: It seems that either This is actually rendering RTFM timer queue (as it implemented for now) useless for low-power applications. Have to patiently wait for #115 to land. |
AFAIS in stm32 land, these are behind device specific debug settings. stm32 uses, for example, the DBG / DBGMCU peripheral to set these settings. We can't do device specific stuff within rtfm so we can't fix this in rtfm. If you change the debug settings (if possible at all) in |
|
Hi
I think we might want to have an RTFM trait for enabling the DWT, that can be implemented for each family of MCUs. What do you think about that?
(There might be other RTFM traits later, for device specific timers, if we want to reduce priority inversion for the timer queue, and dispatch.)
Best
Per
…________________________________
Från: Jorge Aparicio <notifications@github.com>
Skickat: den 8 februari 2019 12:50:52
Till: japaric/cortex-m-rtfm
Kopia: Subscribed
Ämne: Re: [japaric/cortex-m-rtfm] Timer-Queue does not seem to execute tasks when debugger is not attached (#123)
It seems that either DWT cycle counter or SYST is disabled
AFAIS in stm32 land, these are behind device specific debug settings. stm32 uses, for example, the DBG / DBGMCU peripheral to set these settings. We can't do device specific stuff within rtfm so we can't fix this in rtfm. If you change the debug settings (if possible at all) in init then the timer queue will work.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<https://github.com/japaric/cortex-m-rtfm/issues/123#issuecomment-461779062>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AD5naOirMVixPZJ27IC2ySwM4H7qj31fks5vLWScgaJpZM4Zj5XG>.
{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/japaric/cortex-m-rtfm","title":"japaric/cortex-m-rtfm","subtitle":"GitHub repository","main_image_url":"https://github.githubassets.com/images/email/message_cards/header.png","avatar_image_url":"https://github.githubassets.com/images/email/message_cards/avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/japaric/cortex-m-rtfm"}},"updates":{"snippets":[{"icon":"PERSON","message":"@japaric in #123: \u003e It seems that either `DWT` cycle counter or `SYST` is disabled\r\n\r\nAFAIS in stm32 land, these are behind device specific debug settings. stm32 uses, for example, the DBG / DBGMCU peripheral to set these settings. We can't do device specific stuff within rtfm so we can't fix this in rtfm. If you change the debug settings (if possible at all) in `init` then the timer queue will work."}],"action":{"name":"View Issue","url":"https://github.com/japaric/cortex-m-rtfm/issues/123#issuecomment-461779062"}}} [ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/japaric/cortex-m-rtfm/issues/123#issuecomment-461779062", "url": "https://github.com/japaric/cortex-m-rtfm/issues/123#issuecomment-461779062", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]
|
I checked a nRF52840 and the "software lock" feature doesn't seem to be implemented for the DWT (register DWT_LSR reads as zero) -- the CYCCNT increases as expected -- so those PRs will likely not help for that chip. Perhaps there's some device / nRF specific lock that keeps the DWT disabled on reset (its clock could be disabled on reset to save power?). |
|
In v5 it is up to the user to initialize the monotonic timer. |
![https://github.githubassets.com/images/email/message_cards/header.png","avatar_image_url":"https://github.githubassets.com/images/email/message_cards/avatar.png","action":{"name":"Open](https://github.githubassets.com/images/email/message_cards/header.png","avatar_image_url":"https://github.githubassets.com/images/email/message_cards/avatar.png","action":{"name":"Open){kind=link}
123: respect declared unsafety r=therealprof a=japaric
the `#[entry]` and `#[exception]` attributes ignored the declared unsafety and
always expanded to a safe function. This caused the following valid code to
error at compile time:
``` rust
#[entry]
unsafe fn main() -> ! {
foo();
//~^ ERROR call to unsafe function is unsafe and requires unsafe function or block
loop {}
}
unsafe fn foo() {}
```
r? @rust-embedded/cortex-m (anyone)
Co-authored-by: Jorge Aparicio <jorge@japaric.io>
this is a backport of PR rtic-rs#123
I have some examples which do the following:
When the debugger IS attached, both of these features work correctly. When a debugger is NOT attached, only the interrupt driven task functions correctly. I suspect that without the debugger attached, certain trace functionality is not available, preventing the timer from firing correctly. I saw some discussion of this on stack overflow, which might be interesting.
This is likely to be resolved when #115 lands.
The text was updated successfully, but these errors were encountered: