Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Set device.DBG.cr.dbg_sleep to 1 when using wfi in the idle task. #131

Closed
nraynaud opened this issue Jan 15, 2019 · 2 comments
Closed

Set device.DBG.cr.dbg_sleep to 1 when using wfi in the idle task. #131

nraynaud opened this issue Jan 15, 2019 · 2 comments

Comments

@nraynaud
Copy link

nraynaud commented Jan 15, 2019 •
edited
Loading

I was struggling to flash my device with openocd after I started using RTFM while googling I found this message:
https://www.jsykora.info/2014/10/error-jtag-status-contains-invalid-mode-value-communication-failure-solved/

adding this at the top of my init seems to have helped:

	#[init(schedule = [toggle])] 
	unsafe fn init() {
        let dbg = device.DBG;
        dbg.cr.modify(|_, w| w.dbg_sleep().set_bit());
    }
@nraynaud nraynaud reopened this Jan 15, 2019
@japaric
Copy link
Collaborator

japaric commented Feb 8, 2019

let dbg = device.DBG;

This is device specific and can't really be done in rtfm. It could be the case that the device does not have a DBG peripheral; or it may not be named like that; or its registers / bit fields may be named differently; or the svd file may not contain bitfield information.

@nraynaud
Copy link
Author

nraynaud commented Feb 8, 2019

I see.

@nraynaud nraynaud closed this as completed Feb 8, 2019
andrewgazelka pushed a commit to andrewgazelka/cortex-m-rtic that referenced this issue Nov 3, 2021
@bors @adamgreen
Merge rtic-rs#131
a531ee2 
131: Allow GDB to unwind HardFault callstacks r=therealprof a=adamgreen

When I currently request GDB to dump a hard fault stack, I see
something like this:
```
(gdb) bt
#0  UserHardFault_ (ef=0x10001fb8) at /depots/cortex-m-rt/src/lib.rs:537
rtic-rs#1  0x08003fe6 in HardFault ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
```
GDB can't unwind past HardFault since the current implementation of
this function overwrites the Link Register (LR) value. This change
pushes LR and R0 (to maintain 8-byte stack alignment) to the stack
before transferring execution to UserHardFault().

After this change, I see a callstack like this from GDB:
```
(gdb) bt
#0  UserHardFault_ (ef=0x10001fb0) at /depots/cortex-m-rt/src/lib.rs:537
rtic-rs#1  0x08003fe8 in HardFault ()
rtic-rs#2  <signal handler called>
rtic-rs#3  0x08002820 in core::ptr::read_volatile (src=0x48001800) at libcore/ptr.rs:472
rtic-rs#4  0x080001a2 in main () at src/07-registers/src/main.rs:14
```
Notes:
* This code uses 8 more stack bytes.
* Increases the size of the HardFault handler by 2 narrow instructions
  or 4 bytes. This could be decreased to 2 bytes by removing the pop
  since UserHardFault() doesn't currently return but it just looks too
  odd for me to do as an initial attempt.

Co-authored-by: Adam Green <adamgreen@users.noreply.github.com>
andrewgazelka pushed a commit to andrewgazelka/cortex-m-rtic that referenced this issue Nov 3, 2021
@adamgreen
Remove extraneous POP from my prev commit
cb49e52 
Based on the great feedback to PR rtic-rs#131, I have removed the POP
instruction that I added in my previous commit since UserHardFault
never returns.
andrewgazelka pushed a commit to andrewgazelka/cortex-m-rtic that referenced this issue Nov 3, 2021
@bors @adamgreen
Merge rtic-rs#132
1d301db 
132: Remove extraneous POP from my prev commit r=therealprof a=adamgreen

Based on the great feedback to PR rtic-rs#131, I have removed the POP
instruction that I added in my previous commit since UserHardFault
never returns.

Co-authored-by: Adam Green <adamgreen@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@nraynaud @japaric