Flashing STM32MP1 custom board over JTAG

[ANiko.3]

Hello,

I need to flash a custom STM32MP1 board which only has JTAG (no USB port available). Additionally, I build the image using Yocto meaning the output are separate binaries (e.g. U-Boot) and .tsv files.

The STM32CubeProgrammer detects the CPU with the ST-LINK/V2 in-circuit debugger. However trying to flash the device comes with the error:

```

Error: TSV files are not supported with JTAG/SWD debug interface

```​

Could someone give me more info on how I could flash over JTAG and by using the STM32CubeProgrammer? Or how I could flash in any other way (dont forget that Yocto generates separate binaries and the .tsv files).

[PatrickF · Accepted solution]

Hello,

it is unfortunately not possible to program external flash of MPU products using JTAG. USB is mandatory (UART can barely be used too). See https://wiki.st.com/stm32mpu/wiki/STM32CubeProgrammer .

Is you board have a removable SD-Card ? SD-Card might be programmed outside the target. See https://wiki.st.com/stm32mpu/wiki/How_to_populate_the_SD_card_with_dd_command .

Regards.

[PatrickF]

As workaround to your issue, for flashing only purposes, you might wire an USB connector by using only 3 pins (USB_DP2, USB_DM2, VSS).

This will need a modified uBoot to ensure VBUS and ID pins levels are not checked (see https://wiki.st.com/stm32mpu/wiki/How_to_configure_U-Boot_for_your_board#USB_OTG_node)

[ANiko.3]

Hello,

thanks for the answer. Nope, there is no SD-Card reader available, only JTAG.

Regards.

[ANiko.3]

Hello Patrick,

thanks for the answers. Is it somehow possible to boot over JTAG from an external device?

Regards.

[PatrickF]

JTAG is only available for debug/test.

It is possible to use 'Engineering boot' (pins BOOT[2:0] = 0b100) to get access and load FW to Cortex-M4 using CubeIDE.

It is as well possible for Cortex-A7 (e.g. to load TF-A binary in SYSRAM), but I think currently this need to use 3rd party debuggers.

But this is only for development purposes.

Regards.

[ANiko.3]

Hi Patrick,

thanks for the quick answer. There is a USB port on the board, it operates as USB host though. Could it be possible to flash the device over that one by using STMCubeProgrammer or any other tool?

Regards.

[PatrickF]

If your USB host is connected to USB_DP2, USB_DM2 (not possible to flash on USB_DP1/DM1 as this are not connected to OTG IP), you could use a non-standard Type-A/Type-A cable during Flashing (risk of VBUS conflict if not disconnected on the cable, but usually not an issue as protected).

You need a specific uBoot for flashing (usually Id 0x03 in the Flashlayout TSV), different of the one expected to be used (flashed) in your application (other Id in the TSV).

This specific uBoot (loaded in RAM) need to define OTG device to be used for USB_DP2/DM2 whereas you 'normal' uBoot could use USBH.

To force OTG to ignore VBUS and ID (as usually not present), you should add in the Device Tree the force-b-session-valid; and hnp-srp-disable; on the &usbotg_hs node.

[ANiko.3]

Hi Patrick,

my custom board is completely empty (theres nothing on it). Since I need a specific U-Boot for flashing, how could I load it in RAM, is something like that even possible?

Regards.

[PatrickF]

STM32CubeProgrammer, using BootROM DFU, will load TF-A in SYSRAM (mostly to init DDR and manage the load of uBoot) and uBoot in DDR (respectively Id 0x01 and 0x03 in TSV). Then uBoot is started which then communicate with CubeProgrammer to start the Flashing (wich start with one or mode TF-A, uBoot, etc...). Please look at TSV examples provided with starter package.

Obviously, all the binaries should be tailored to your board and system config.

#Opt	Id	Name	Type	IP	Offset	Binary
-	0x01	fsbl1-boot	Binary	none	0x0	arm-trusted-firmware/tf-a-stm32mp157c-dk2-serialboot.stm32
-	0x03	ssbl-boot	Binary	none	0x0	bootloader/u-boot-stm32mp157c-dk2-optee-flasher.stm32 <== this one should use OTG on USB_DP2/DM2 in your case
P	0x04	fsbl1	Binary	mmc0	0x00004400	arm-trusted-firmware/tf-a-stm32mp157c-dk2-trusted.stm32
P	0x05	fsbl2	Binary	mmc0	0x00044400	arm-trusted-firmware/tf-a-stm32mp157c-dk2-trusted.stm32
PD	0x06	ssbl	Binary	mmc0	0x00084400	bootloader/u-boot-trusted-stm32mp157c_dk2.stm32    <== this one should use USBH on USB_DP2/DM2 in your case
PD	0x0A	teeh	Binary	mmc0	0x00284400	optee/tee-header_v2-stm32mp157c-dk2-optee.stm32
P	0x0B	teed	Binary	mmc0	0x002C4400	optee/tee-pageable_v2-stm32mp157c-dk2-optee.stm32
P	0x0C	teex	Binary	mmc0	0x00344400	optee/tee-pager_v2-stm32mp157c-dk2-optee.stm32
P	0x21	boot	System	mmc0	0x00384400	st-image-oss-bootfs-openstlinux-weston-stm32mp1-disco-oss.ext4
P	0x22	rootfs	FileSystem	mmc0	0x04384400	st-image-weston-openstlinux-weston-stm32mp1-disco-oss.ext4