Add DCB::enable_trace() and DCB::disable_trace()

[kellerkindt]

This is required for the cycle counter of DWT to work, if the power supply has been unplugged since the last time it has been flashed japaric/stm32f103xx-hal/issues/76.
See bit 24 here http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0337e/CEGHJDCF.html

Corresponding PR in stm32f103xx-hal: japaric/stm32f103xx-hal/pull/94

[kellerkindt]

Also, a PR for the MonoTimer in stm32f103xx-hal (calling enable_trace() before enable_cycle_counter()) will follow, as soon as I can fix these local dependency issues, which occured once I updated to the latest version of cortex-m. But this might be an easier PR, if this one was already merged then.

166 |     let timer = ::stm32f103xx_hal::time::MonoTimer::new(cp.DWT, clocks);
    |                                                         ^^^^^^ expected struct `stm32f103xx::DWT`, found struct `cortex_m::peripheral::DWT`
    |
    = note: expected type `stm32f103xx::DWT`
               found type `cortex_m::peripheral::DWT`

Anyone familiar with this error?

EDIT: Now having this issue

warning: Linking globals named 'CORE_PERIPHERALS': symbol multiply defined!

error: failed to load bc of "cortex_m.8ussh43s-cgu.6": 

EDIT2: Got it working, had two different versions of cortex-m in local and indirect dependencies, fixed via [replace] in the Cargo.toml .

[korken89]

Hi, good catch!
I will approve for now but wait a bit for more comments from @rust-embedded/cortex-m if they want to change something.

[thejpster]

It's a read/modify/write but it takes a mut ref, so that's ok. I think I'd prefer 1 << 24 to be a const instead of being duplicated, but that's pretty minor. Happy as is really.

[adamgreig]

👍 for the feature, but I would also really prefer a DWTENA const instead of 1<<24. Also I don't think this PR should bump the crate version number; we'll do that when ready to release.

[kellerkindt]

@thejpster @adamgreig Just moved the the shift to the constant BIT_TRCENA (since TRCENA is used in the arm documentation).

@adamgreig The version bump is needed by japaric/stm32f103xx-hal/pull/94, but I am open for other suggestions to resolve that.

[adamgreig]

Oh I see, in ARMv6-M it's DWTENA but in ARMv7-M it's TRCENA. That's fine. Could you use something like DCB_DEMCR_TRCENA instead of BIT_TRCENA and 1 << 24 instead of 0x01 << 24 to be consistent with the other modules?

For the version number, it still shouldn't be updated in this PR - once this PR is landed and we're ready to cut a new release (which can be essentially right away) there will be a new PR for the new release (updating the changelog too), and once that's published on crates.io your PR to stm32f103xx-hal will be possible to merge.

[adamgreig]

Thanks! LGTM, I'll approve but I'll let @korken89 re-approve and merge if they're happy since they reviewed it earlier.

[kellerkindt]

@adamgreig Here you go :)

Who is going to to handle the PR for the new version? At my location its quite late and I need to get up early tomorrow. So no new commits/comments from me for the next 18h to 20h.

[therealprof]

LGTM, too.

[korken89]

Thanks for the extra checks and changes all!

bors r+

[bors]

Build succeeded

• continuous-integration/travis-ci/push