Hi Kever,
On 2/18/24 02:14, Kever Yang wrote:
Hi Quentin,
On 2024/2/9 21:18, Quentin Schulz wrote:
From: Quentin Schulzquentin.schulz@theobroma-systems.com
The STM32_RST line is routed to the ATtiny microcontroller PA0/RESET/UPDI pin. By driving the PX30 SoC pin as GPIO output high, we prevent external UPDI to be used for flashing without first putting this pin as GPIO input, an extra step we could avoid in userspace.
A little confuse here, this GPIO is an output for PX30, right?So the config is:
- the PX30 SPL init STM32_RST as input, with hardware pull-up the keep
STM32 work;
The pin needs to be high for STM32, and high **but not driven** for ATtiny in order to allow flashing scripts to work.
- when need UPDI for flashing, need to set STM32_RST to output and
trigger the reset in userspace?
For STM32, STM32_RST needs to be driven low, then STM32_BOOT needs to be driven high, then STM32_RST needs to be high to deassert reset.
For ATtiny, STM32_RST needs to be NOT driven so that UPDI lines can be used to interact with the MCU. Note that we also have the ability to do bitbang UPDI on that STM32_RST pin but that's another topic (just explaining why it is routed while seemingly useless for ATtiny).
All the above is for entering the flashing mode.
However, in U-Boot we do NOT want to enter flashing mode, we want to exit it, c.f. https://lore.kernel.org/u-boot/20231103-ringneck-stm32-reset-v2-1-a0e5559f89...
An external HW pull-up is required because of glitches on the line when powering up/down. However, this is only done on newer versions of the PCB, so we need to tackle old versions.
The old versions do not have this external HW pull-up and the glitch may cause the MCU to enter its flashing mode. Therefore, we force it to exit the flashing mode by always hard resetting it into the normal runtime mode. This is what spl_board_init() does. STM32_RST and STM32_BOOT are controlled by our flashing script for the STM32 variant for the MCU, so the default state when entering the Linux kernel doesn't matter. For the ATtiny MCU variant, we do not handle those GPIOs as part of the flashing script, therefore the default state when entering the Linux kernel should be the expected value for which we can use UPDI to flash the ATtiny. For ATtiny, the reset line is shared between STM32_RST that goes to the SoC and the UPDI lines exposed over the Q7 header. If STM32_RST is driven by the SoC, the UPDI lines won't be able to interact with the MCU. Therefore it needs to be put into input mode, whether in U-Boot or in Linux userspace.
There's an external hardware pull-up strong enough to keep the STM32_RST state high on ATtiny side but weak enough it can be overridden by external UPDI. This also means it is safe to use for the STM32 variant, where STM32_RST line will be in the same state as if output high was used.
The Q7 standard specifies that MFG_NC1 and MFG_NC2 (used for UPDI for Ringneck) pins should neither be driven by the carrierboard, nor have pull-up or pull-down resistors.
This sounds like it should use output and pull-none for these GPIOs?
This would be a configuration for the Linux kernel DT, but we would still need some custom handling in U-Boot. What are you suggesting exactly with this?
Cheers, Quentin