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

It sounds like you’re already on the right track using serial boot mode. Yes — you can upload small custom programs as long as they follow the bootloader format expected by the STM32MP13 ROM. Many engineers use minimal loaders to test board features when JTAG isn’t available. Just make sure your code fully initializes clocks, DDR/eMMC, and any peripherals you want to test, since nothing is pre-configured in serial boot mode.

I usually cover entertainment content on my site https://famouscelebritiespics.com/ , but I also enjoy following interesting hardware discussions like this.

[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()?

 

[PatrickF]

I'm not SW expert, but using other pins for UART (I guess you have some free pins on your board were you can plug RX/TX) is matter of updating this file https://github.com/STMicroelectronics/STM32DDRFW-UTIL/blob/main/DDR_Tool/STM32MP135C-DK/Inc/stm32mp_util_conf.h in the STM32MP135C-DK CubeIDE project (of a new cloned one) as described in https://github.com/STMicroelectronics/STM32DDRFW-UTIL?tab=readme-ov-file#1233-customization 

 

I assume that for your specific project constrains, choosing an MPU (STM32MP family) rather than MCU (other STM32 families) has been done with carefully assuming that learning curve for those is much steep and deserve solid embedded FW team background.
Alternatively, there is plenty of ready made HW as well as HW and SW partners available (https://www.st.com/content/st_com/en/partner/partner-program.html).

 

I cannot help much more on my side but maybe some peers in the ST Community have worked on a similar project and can share their experience here.

Do not hesitate to create new posts on specific points you want helps. It is very hard to manage wide questions on a single post.

 

Regards.