Can I connect a I2C device to the SWDIO and SWCLK pins, and program the microcontroller using BOOT0 pin, and then use I2C on these pins?
Will there be no interference from the I2C device when programming the STM32?
Or should I physically disconnect the I2C device while programming?
\$\begingroup\$
\$\endgroup\$
2
-
\$\begingroup\$ What you are describing sounds like you are confused how to program the MCU. You don't need BOOT0 pin to enter factory bootloader if you use SWD pins for programming, and you don't need SWD pins if you use BOOT0 to use the factory bootloader. How do you intend to program the MCU, via SWD, or via factory bootloader using the BOOT0 pin? If the latter, which interface you intend to use, UART, USB, or something else? Which of course depends on which exact MCU you have, but won't reveal. \$\endgroup\$– JustmeJul 20 at 9:54
-
\$\begingroup\$ Providing exact MCU model would go a long way to the mutual understanding \$\endgroup\$– MapleJul 20 at 18:43
Add a comment
|
2 Answers
\$\begingroup\$
\$\endgroup\$
2
your board design needs to be such that the I2C connection does not adversely interfere with the SWD when both are connected to these pins at the same time.
You use words like "program" SWD can be used to "program" as well as "debug".
Thus far your use case sounds like. Can I use the boot0 pin (and reset) to put the STM32 (too broad btw) into a mode where I can use SWD to "program" (the application flash on the) mcu. Yes you can so long as electrically the SWD and I2C are not interfering with each other in that mode. If the I2C is a slave for example and is basically dormant even with power because the MCU is not asking it anything.
I would have to check datasheets but historically boot0 plus reset puts you into the internal factory bootloader. But ST has gone away from this in their new parts. Erased flashes you will get the traditional bootloader, for uart, usb, etc. But once programmed an internal set of boot "pins"/values are used and you cannot get into that bootloader (unless you prepare/set these non-volatile bits to a legacy mode, use the external not the internal).
Which means you will continue to boot into your application, if your application changes the pins to an alternate function (i2c) then those pins are internally disconnected from the swd module. And swd will not work even with boot0 and reset. So that is a tangent but generically saying "STM32" you have to understand all STM32 parts do not work the same.
Saying that. If you use boot0 plus reset to put the STM32 part into the bootloader, then the swd pins will not be changed to some alternate function. and you can (re)program the device. You are free to use any of the alternate functions for those pins as part of your application, I2C, uart, whatever, your choice just like any other gpio pins on the part. What you cannot do (assumed but obvious, you can simply try this) is have the pins muxed to the I2C, and try to "debug" over SWD on the same pins at the same time. There is no reason to expect that could ever work.
And then it circles back to the electrical design of the board. If the board design as well as i2c device(s) connected pull or push the signals on these pins in a way that interferes with the SWD debugger, when hooked up, to speak that protocol to the chip then the "system" is a failure you cant have both hooked up and then you need to consider not using the pins for anything else and/or some switch or connector or other mechanical or electrical solution to isolate the I2C and SWD external devices such that they do not interfere with each other. (same goes for if you want to leave an SWD debugger hooked up permanently that overall pcb/system design needs to be such that it does not interfere with I2C when using those pins for I2C)
That assumes one interpretation of your question. Another may be are you asking that in the bootloader mode on parts that have i2c as a programming interface, does that bootloader for that specific stm32 part, have a way to detect i2c OR swd on those pins. I think/know of parts where the two pins are both the SWD pins and the uart pins used for/by the bootloader, and I think it worked for me to use the uart.
I would not use the terminology "SWDIO and SWCLK" pins. That is not what they they are like PA9 and PA10 or something like that. What they connect to internally is determined by the alternate function mux. They may default to a particular function and be an uart rx/tx or swd io or clk, etc. I wouldnt say can I do i2c on "swd pins"...
Or maybe there is a third interpretation of your question...end of the day, what did you try and what was the result...
-
\$\begingroup\$ Thank you for your clear, unoffending answer. I think it is just a wording issue, but you say: "And swd will not work even with boot0 and reset." and then " If you use boot0 plus reset to put the STM32 part into the bootloader, then the swd pins will not be changed to some alternate function." I believe the latter brings the correct message. \$\endgroup\$– kubajedJul 21 at 5:56
-
\$\begingroup\$ the stm32g parts if I remember right, once programmed once, boot0 plus reset will NOT put it in the bootloader. unless you change some non-volatile registers. most other stm32 parts will... \$\endgroup\$ Jul 21 at 7:05
\$\begingroup\$
\$\endgroup\$
5
can I connect a i2c device to the SWDIO and SWCLK pins,
Maybe. On some microcontrollers, you can re-assign the debug pins to take other roles, maybe even I²C. Your specific device's datasheet is the only place you can look up what is possible there.
It does sound like a relatively bad idea to get rid of the debug interface, considering that you're still developing your MCU skills!
If you don't know how to use your debugger yet, I recommend you learn that before you start communicating with other devices.
A and program the microcontroller using BOOT0 pin,
no.
To be honest, your question really reads like you're a bit confused about what these pins are for. Maybe spending a bit of time with the User Guide and the data sheet for your specific model of the STM32 series will help.
answered Jul 20 at 10:07
-
\$\begingroup\$ BOOT0 pin has o be pulled down to enter reset mode, to assign SWD pins their default roles. Without this pin, I won't be able to program the STM more than once, as these pins will have other roles (i2c) assigned. \$\endgroup\$– kubajedJul 20 at 10:55
-
\$\begingroup\$ That's not right; as said, your software is free to assign roles to pins, nothing there limits you to never use these debug pins (that would be stupid, why include debug pins when they can't be used once software has been loaded?). Read. the. user guide. \$\endgroup\$ Jul 20 at 11:55
-
\$\begingroup\$ Unfortunately you don't understand me. I know that I'm free to assign roles. But once assigned, let's say i2c on SWD pins, how would you use them to program the uC, otherwise than pulling the BOOT0 pin to enter reset mode? \$\endgroup\$– kubajedJul 20 at 12:33
-
\$\begingroup\$ I do understand you. You would do that by either having your firmware re-assign them to be SWD, or by simply implementing a self-programmer in your firmware. the boot0 pin has literally nothing to do with your choice of software. \$\endgroup\$ Jul 20 at 12:35
-
\$\begingroup\$ @kubajed You keep using "BOOT0" and "enter reset mode" in one sentence. BOOT0 has nothing to do with reset. It only defines boot address (hence the name) after reset. The MCU can execute either your program from flash (which will re-configure pins for I2C) or system bootloader from ROM (which will check periphery for incoming programming connections). On some chips an EEPROM or second flash space are also available to boot from. Having said that, system bootloader does not change SWD pins, which means you may be able to use SWD for programming, as old_timer mentioned in his answer. \$\endgroup\$– MapleJul 20 at 19:00