Closed MauroMombelli closed 5 years ago
Hi @MauroMombelli , Well, by default PB3 and PB4 pins are mapped to TDO/TRACESWO and NJTRST functions respectively. Tweaking debug option in Cargo.toml does not remap them into GPIO. So you need to do the following before switching those pins to push/pull GPIO output:
// Configure TDO/TRACESWO as PB3 and NJTRST as PB4
afio.mapr
.mapr()
.modify(|_, w| unsafe { w.swj_cfg().bits(0b010) });
You may refer to section 9.3.5 in Reference manual for stm32f10x MCU for more details.
By the way, alternatively, if you don't need JTAG/SWD at all in runtime, you may use the following call:
afio.mapr.disable_jtag();
Regards, Sergey
The reason why I disabled the debug in the toml. Problem is PB4 start high, and this is not good on my board; I need to disable this debug at startup.
Also this debug stuff should be optional, normally disabled, and SWD can work fine without.
So my suggestion is, if you really want to keep this enabled by default if not a big warning, at least put a mention on the docs :/
On Mon, Jul 8, 2019, 10:27 Sergey Matyukevich notifications@github.com wrote:
Hi @MauroMombelli https://github.com/MauroMombelli , Well, by default PB3 and PB4 pins are mapped to TDO/TRACESWO and NJTRST functions respectively. Tweaking debug option in Cargo.toml does not remap them into GPIO. So you need to do the following before switching those pins to push/pull GPIO output:
// Configure TDO/TRACESWO as PB3 and NJTRST as PB4 afio.mapr .mapr() .modify(|_, w| unsafe { w.swj_cfg().bits(0b010) });
You may refer to section 9.3.5 in Reference manual for stm32f10x MCU https://www.st.com/content/ccc/resource/technical/document/reference_manual/59/b9/ba/7f/11/af/43/d5/CD00171190.pdf/files/CD00171190.pdf/jcr:content/translations/en.CD00171190.pdf for more details.
By the way, alternatively, if you don't need JTAG/SWD at all in runtime, you may use the following call:
afio.mapr.disable_jtag();
Regards, Sergey
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/stm32-rs/stm32f1xx-hal/issues/77?email_source=notifications&email_token=ABQTZUOPCH72VMFEMZ3NAG3P6L27VA5CNFSM4H6WZKG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZMLMLQ#issuecomment-509130286, or mute the thread https://github.com/notifications/unsubscribe-auth/ABQTZUJELXGKNQRTULND27TP6L27VANCNFSM4H6WZKGQ .
Hmm... I don't think I understand you. This is not about Rust or Cargo, it is about hardware properties. By default those pins are mapped to JTAG/SWD functions on MCU startup. You are free to remap them in your code and keep using PB3 and PB4 as normal GPIOs. And the simplest way to do it is to use disable_jtag() method mentioned above. As for debug option in Cargo.toml, it does not control hardware (e.g. pin mapping), it controls availability of debug info in resulting binary.
By default those pins are mapped to JTAG/SWD functions on MCU startup
oh, you got me curious and indeed they are debug on reset, so somehow i got lucky to not have problem with bare CMSIS (will have to take a look into it, maybe is a compilation setting), as I am porting known working C code I assumed by default only SWD was enabled (so PB3, PB4 and PA15 released, and only PA13 and PA14 used by SWD)
afio.mapr.disable_jtag();
this is confusing, will disable both jtag and swd or jtag only? (see table below for different possible setup, RM0008 Rev 20 page 177/1134)
010 in your table, so only jtag
thanks, I just took a more direct approach and tested directly, and can confirm it works, closing.
Just as quick info, this mean I could use some pin as usart and while in use, also use them as gpio or other, right? the library is not preventing this kind of error? or is just a weird edge case that need a bugfix?
Huh? No, it should not let you do that.
then the code in the first post should have return compilation error as I use those pin as GPIO but they should have been "consumed" by the jtag, no?
This library doesn't handle correctly the starting state of the debugger pins. That's a tricky fix.
Rust ownership system will not allow you to use a pin as UART and GPIO at the same time, it will just not compile, except if you cheet with unsafe.
Well, it might be possible to work around that by utilising a special state which the PINs are in by default and to get them into one of the regular states you'd have to call a special function. If someone wants to do a PR to implement that it would be welcome.
thanks guys, this is very interesting and while I would participate a lot in the discussion, right now I don't even know what this code is actually doing, so maybe in a couple of years :)
Hi,
after managing to run the demo blink on led PC13, I wanted to also blink led on PB3, PB4 and PB5.
PC13 and PB5 works fine, PB3 and PB4 don't. I am aware they may be used for some debug stuff but I set debug to false to Cargo.toml. Also if pin would be in use by something else, i would expect compilation error
full code:
cargo.toml