Do I absolutely have to have a bootloader during development for a custom STM32MP13 board?

[cbcooper]

I've got a custom board built around an STM32MP135AAE3.  It's designed to have an eMMC instead of an SD card, the problem is that the board was not laid out correctly and the JTAG isn't connected.

I'm having trouble writing to the eMMC (that's another topic) but I'm trying to make some progress while waiting for a board spin.  The board is in serial boot mode so I'm able to upload bootloaders, am I allowed to upload any arbitrary program and call it a bootloader?  I'm thinking I could start testing board features by uploading small programs to test the board if that's allowed with a "bootloader".

[PatrickF]

Hi,

yes, you could load, with BootROM in USB DFU, any piece of code which will run from internal SYSRAM (work similarly when BootROM load from external Flash to SYSRAM).
Code must be < 128KB (https://wiki.st.com/stm32mpu/wiki/STM32_MPU_ROM_code_overview#Memory_mapping)
Code should be signed, even using dummy keys (i.e. include header). https://wiki.st.com/stm32mpu/wiki/STM32_header_for_binary_files#On_STM32MP1-lines 

https://wiki.st.com/stm32mpu/wiki/Signing_tool 

Loading/executing bare-metal code into SYSRAM is exactly what is done with DDRFW-UTIL (https://github.com/STMicroelectronics/STM32DDRFW-UTIL/tree/main// ) to run DDR tests.

Regards.

[cbcooper]

Maybe there's another problem with this board ... it looks like BOOT0 is pulled low and BOOT1 and BOOT2 are pulled high which should mean serial boot mode, but what I'm seeing in STM32CubeProgrammer is this:

ChatGPT says I should be seeing STM32CubeProgrammer downloading a small loader into the system's RAM automatically, something like this:

Downloading built-in loader...
Loader successfully executed.

and that since I'm seeing DFU mode, that indicates my STM32 isn't actually in serial boot mode.  Is it right?

[PatrickF]

Hi @cbcooper 

"serial boot" mean UART or USB DFU (USB is a serial device).

https://wiki.st.com/stm32mpu/wiki/STM32_MPU_ROM_code_overview#Serial_boot

Regards

[cbcooper]

Hi Patrick,

Yes, I realize "serial boot" applies to either UART or USB.  

IT'S NOT WORKING

When I follow the instructions in the DDRFW-UTIL tool repo, it makes it very clear from step one that ST-LINK is required (although, confusingly, the diagram immediately below suggests otherwise).  But when I get down to section 2.2.4 "Launch project" it says I should select my debug configuration and in that dialog my ONLY option is "thru JTAG/SWD link".

Remember that on this board I do NOT have JTAG or SD.

Patrick you are very knowledgeable but I'm guessing that since you often respond at 11 pm that you are in STM HQ in Switzerland?  This project is way behind schedule and being in different time zones is not going to work.  Is there a way I can work directly with a local STM person (I'm in Colorado), maybe even over zoom or something?  We will certainly pay for a higher level of support.

[PatrickF]

Hi @cbcooper 

you could try getting local support using

ST Online Support Center

Online support requests can be submitted https://my.st.com/ols.

Regards

[PatrickF]

Hi @cbcooper 

could you try following (I did not tested on MP13-DK, but work on my MP15-DK board).

• connect UART console to the board (Bps=115200 Bit=8 Parity=None Stop=1).
  • Default UART for pre-compiled STM32MP135C-DK_DDR_UTILITIES_A7.stm32 is UART4 on pins PD6 (TX) and PD8 (RX). If your board use different port, you should recompile the SW.
• connect USB DFU to PC
• power you board
• run following CubeProg on command line (might need to adapt to your environment)

  • "%ProgramFiles%\STMicroelectronics\STM32Cube\STM32CubeProgrammer\bin\STM32_Programmer_CLI.exe" -c port=usb1 -w STM32MP135C-DK_DDR_UTILITIES_A7.stm32 0x01 --start 0x01
    

You should then being able to see prompt on the console like https://github.com/STMicroelectronics/STM32DDRFW-UTIL/blob/main/README.md#2312-command-examples 

If not, need to debug your HW (and SW), but would be hard without JTAG/SWD).

SW might need to be recompiled if your board does not use exactly same HW setup than STM32MP135C-DK board (mostly UART port, I2C pins for STPMIC1, power supplies for DDR)

Might be worth for you to get a board https://www.st.com/en/evaluation-tools/stm32mp135f-dk.html to being able to start some development/trials on a working and supported HW.

Regards.

[cbcooper]

Alas no UART, only USB.  PD6 goes to RMII_REFCK and PD8 is not connected at all.

Running your command line on an un-modified STM32MP135C-DK_DDR_UTILITIES_A7.stm32 seemed to do something at least:

[PatrickF]

Hi @cbcooper 

a board without UART, without JTAG will give you some hard time....

At least, you should recompile the SW to use different UART pins (and use an FTDI like UART<->USB cable or an STLINK-V3SET which could act as VCP even without using JTAG/SWD).

Regards.

[cbcooper]

It looks like switching to using USB instead of UART is more than just pointing to different UART pins?  Don't I have to rewrite __io_putchar() to talk to USB instead of calling HAL_UART_Transmit()?