Hi Kever,
On 2/19/24 10:50, Quentin Schulz wrote:
Hi Kever,
On 2/18/24 02:14, Kever Yang wrote:
Hi Quentin,
On 2024/2/9 21:18, Quentin Schulz wrote:
From: Quentin Schulz<quentin.sch...@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:
1. 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.
2. 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-a0e5559f8...@theobroma-systems.com/
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.
Can we have this in the next merge request for next please? Or maybe
there's something I need to change here?
Cheers,
Quentin
