search

japaric / stm32f103xx-hal

HAL for the STM32F103xx family of microcontrollers
Apache License 2.0
116 stars 40 forks source link

PB3, PB4 and PA15 are unavailable unless the JTAG is disabled #116

Open TheZoq2 opened 5 years ago

TheZoq2 commented 5 years ago

The pins PB3, PB4 and PA15 are used for JTAG debuging on this chip which means that they are normally unavailable for general use. It is possible to use them if you disable the JTAG device as noted in section 31.4.4 of the manual.

Disabling the jtag device should be fairly straight forward since you can still use the SWJ debugger and i'll submit a PR that adds a function for doing that. However, since the JTAG device is enabled by default, those pins are unusable until it's disabled which is not reflected in the current API. I spent a few hours debugging this today and I imagine others will or already have as well.

Would it make sense to prevent usage of those three pins until the JTAG is disabled? Perhaps by adding another GPIO type: jtag and requiring a token type given by the JTAG disable function to enable them?

lorenz commented 5 years ago

Related to #83

TeXitoi commented 5 years ago

I agree that it would be better to have a Debugger type state.

TheZoq2 commented 5 years ago

I had a look at this again and it seems like implementing a debugger type state might not be as simple as I thought. The problem is that all the into_<pin mode> functions are blanket implemented for all pins.

Therefore, simply adding a Debug type state would not prevent a user from changing out of that mode without first disabling the debugging functionality. The neatest solution to this in my opinion would be to change those impls to

impl<MODE> for $PXi<MODE> where MODE: !Debug

However, negative traits do not yet seem to be implemented in the language.

One possible solution is to add a trait like NotDebug which would be implemented by all the other modes. Then we could impl pin changes for all modes that are NotDebug. It kind of feels like a hack but in my opinion, statically preventing mistakes where pins don't work is a good cause to introduce such a hack until negative traits are implemented, do you agree?

TheZoq2 commented 5 years ago

I went ahead and implemented the solution I mentioned above in a branch of my fork here: https://github.com/TheZoq2/stm32f103xx-hal/tree/debug_pin_state

It's not as messy as I thought it would be, do you think it's good enough and I should open a PR for this? @TeXitoi

lorenz commented 5 years ago

Not sure I like the use of a token. What do you think about having some sort of debug device which owns the pins by default but by destroying (and thus consuming the device) one gets access to these pins?

TheZoq2 commented 5 years ago

That does sound like a better solution, I'll look into implementing it

TeXitoi commented 5 years ago

I agree debug device seems better.