Problems with ecosystem & STM32MP157C-EV1 and how to get STM32CubeProgrammer working with it

[DEdwa.1]

I'm trying to get STM32MP157C-EV1 board working with the STM32Cube ecosystem.

I've had a lot of issues - the documentation isn't well "connected" re. no "getting started" guide with the board. I eventually found the wiki pages - would be *very* useful if these were mentioned on the STM32MP1 resources webpage!).

The wiki pages describe using the now deprecated SW4STM32 rather than STM32CubeIDE, and whilst it describes setting the boot pins to boot from SDCARD the section on developing on the M4 doesn't say to set them to "engineering mode" (confusingly referred to as "Reserved (No Boot)" in the STM32MP1 reference manual. The board was also supplied without the jumpers being in the documented default settings, but that's another issue ;-)

I've eventually got a partially working system using an external J-Link and also with the internal ST-Link (despite the ST-Link firmware version being wrongly reported in many of the tools which confused me at first, and the ST-Link GDB server having a command mismatch with the CubeIDE MI commands - using the OpenOCD connection seems to work fine though).

Thus I can use CubeIDE to access the board (albiet only with J-Link or the inbuilt ST-Link in OpenOCD configuration only.

However, I can't set STM32CubeProgrammer to work at all - connecting via the inbuilt ST-Link always reports "Error: No STM32 target found!".

It also doesn't terminate properly - nothing happens when trying to close the main window, so I have to kill the Java process.

I'm using V2.3.0 on Windows 10 and as above, the ST-Link seems to work otherwise (with caveats as above).

Please can you suggest what the problem might be and what do try to get it working.

Cheers!

[PatrickF]

Hello,

I agree that we have some room of improvement. Note that STM32MP1 family ecosystem is still in development to add new exciting features, and I hope it will become better in time.

For your STM32CubePro issue, I think there is a common misunderstanding Vs STM32 MCUs as STLINK JTAG/SWD interface is not used for Flashload with STM32 MPU families. JTAG/SWD will be too slow for hundreds of MBytes of data.

CubeProgrammer use USB for data transfer during STM32MP1 series Flashload. In that case, embedded STLINK is only used to present a Virtual Comm Port for message console (optional).

Apart board flashing, STLINK is obviously used for debug purpose when used with CubeIDE and can be used to load Cortex-M4 code into RAM when debugging without a running Linux (Engineering mode).

When debugging with Linux running (production mode), Ethernet (or Ethernet over USB) is used. In that case, embedded STLINK is only used to present a Virtual Comm Port for message console

For EV1 USB connection, please see section 4 of https://wiki.st.com/stm32mpu/wiki/Getting_started/STM32MP1_boards/STM32MP157x-EV1/Let%27s_start/Unpack_the_STM32MP157x-EV1_board

For programming the SD-Card using CubeProgrammer, please have a look to section 5 of https://wiki.st.com/stm32mpu/wiki/Getting_started/STM32MP1_boards/STM32MP157x-EV1/Let's_start/Populate_the_target_and_boot_the_image

Regards

[DEdwa.1]

Hi Patrick,

Thanks for the email.

I understand the points you are making about JTAG/SWD usage for download, but it still doesn't solve my problem.

I followed the information in those wiki pages and as I mentioned I've got the ST-Link able to access the M4 and can run programs which use the Virtual Com Port so I believe everything is connected fine.

I'm trying to use the CubeProgrammer tool to setup some tests which we'll use on our own board.

Re. my specific questions on STM32CubeProgrammer V2.3.0:

> It also doesn't terminate properly - nothing happens when trying to close the main window, so I have to kill the Java process.

This just seems to be a bug, and is a pain but isn't a killer problem as everything seems to recover once I've killed the Java SE environment.

> , I can't set STM32CubeProgrammer to work at all - connecting via the inbuilt ST-Link always reports "Error: No STM32 target found!".

Its not clear what this error means - the STM32 target can be found by other tools (as I can run code on the M4) and the VCP can be found as I've succesfully used it from the M4. Thus I don't know why its reporting an error

Do you have any more information on what this error means or ideas for things to try?

Cheers,

[PatrickF]

Hello,

I remind that for STM32MP1 series, ST-Link JTAG/SWD connection is useless for CubeProgrammer, which uses USB only.

Please have a try using Command Line Interface (CLI)

1) Connect the EV1 USB OTG connector to your PC

2) Set the Boot switch to Serial-Boot (0b000) and reset the board

3) On PC, get the device port location for the USB link

STM32_Programmer_CLI -l usb

check the "Device Index". DFU driver should have been installed during the CubeProgrammer installation.

4) Issue the board programming command (from board images location, e.g. stm32mp1-openstlinux-4.19-thud-mp1-19-10-09/images/stm32mp1)

STM32_Programmer_CLI -c port=usb1 -w flashlayout_st-image-weston/FlashLayout_sdcard_stm32mp157c-ev1-trusted.tsv

Regards

[DEdwa.1]

Hi Patrick,

Firstly my accept my apologies for the huge time I've taken to reply to your last message.

I'm glad to report I managed to get it to work using the GUI version of the tool afterall - the problem was the settings of the boot pins.

I discovered the fix when trying to use the STM32CubeIDE's CubeMX DDR tools to upload the U-Boot SPL image. Our custom board uses an STM32MP151C and I've been trialing things on the STM32MP157C-EV1 board hence a mixture of MP151 and MP157 references below (I understand these aspects are compatible between the devices)

I tried setting the boot pins using what's described in the DS12501 (the STM32MP151C) reference manual as "UART and USB mode (1)" (BOOT0=OFF, BOOT1=ON, BOOT2=ON) - this boot pin setting isn't described at all in Fig 7 of UM2535 (the STM32MP157-EV1 board user manual). When this setting is used, STM32CubeProgrammer could connect to the board succesfully.

The setting you described as "serial boot mode" (BOOT0=OFF, BOOT1=OFF, BOOT2=OFF) also worked (in Fig 7 of UM2535 this is described as "Forced USB boot for flashing" or "UART and USB(1)" in DS12501).

Thanks for your help with this!

My feedback is for the documentation team - this might help others avoid the same problems I hit:

• The same names for boot pin configurations settings should be used across all the documents (Cube*, reference manuals,device datasheets, and eval board user manuals)
• Tools which need specific boot pin configuration settings should be explicit about this in their documentation/online help and should use the same names for these settings as all the other documents.

Cheers!

[PatrickF]

Hello,

Glad to see your issue is solved. Thanks for the feedback.

I agree that consistency in documentation is not always as good as it should be. With the huge set of documentations for each product, it is a really complex task as handled by different teams at different project time. Let's say, we try to enhance in the future updates !

For the pin settings related to CubeProgrammer usage, it is not so simple and usually not described in tool documentations, and I agree that sometimes it need some good insight on the product. For instance, with STM32MP1 you could power up your board with BOOT[]='Serial-NOR' (e.g. the normal boot of the product), but if the Serial-NOR content is not valid (e.g. blank flash or corrupted FSBL header), the BootROM will fall back on 'UART and USB' (aka 'Serial' in some places) boot mode.

This flow is explained in https://wiki.st.com/stm32mpu/wiki/STM32MP15_ROM_code_overview#Boot_interface_selection and in AN5031.

Regards.