Adapt Openbootloader to other MCUs

[maxschommer]

I'd like to adapt Openbootloader to the H523/H533 chip.

In STM32CubeIDE, there are example applications for several microcontrollers/development boards. I noticed there was an example for the STM32H5731-DK, but I'd like to use it on the H523/H533 chips.

• It would be great if somewhere in the documentation there was information on what needs to change to adapt to other chips
• I have been trying to edit openbootlader_conf.h, but have been struggling to find certain values in the H533/H523 reference manual or data sheet
  • OB_SIZE (and other option bytes related fields)
    • I see Table 51, which has option bytes listed, but when I count them I can't re-create the 432 number which is in the openbootloader_conf.h for the H573 chip. I also can't find references to OB_START_ADDRESS or OB2_START_ADDRESS when I search for the actual hex value in the openbootloader_conf.h for the H573 chip (0x40022050U)
  • ICP_SIZE
    • Also ICP_START_ADDRESS. Searching the reference manual for ICP gives 9 results, none of which are relevant
• EB_SIZE
  • Also EB_START_ADDRESS. I'm not sure what Engi bytes are, is that short for Engine, and refers to the Crypto Engine?

Here is a link to the reference manual I'm referring to:

https://www.st.com/resource/en/reference_manual/rm0481-stm32h52333xx-stm32h56263xx-and-stm32h573xx-armbased-32bit-mcus-stmicroelectronics.pdf

Is there anything else I need to change to adapt examples to a given chip?

[maxschommer]

P.S.

I have the bootloader successfully connecting and reading option bytes over UART on the H533 Nucleo with the attached openbootloader_conf.h. Some changes I had to make it work:

1. Remove threadx and instead just run OpenBootloader_ProtocolDetection() in an infinite loop
2. Remove some of the peripherals (I only need FDCAN) to get rid of a hard fault which occurred in OpenBootloader_Init
3. Remove those same peripherals from the System_DeInit function
4. Switch the UART pins to those used by the on-board STLink for virtual COM (I'm using the H533 Nucleo)
5. Change my linker script to the STM32H533RETX_FLASH.ld generated by a new project by CubeIDE for my nucleo

 

It's not working perfectly however, I'm getting the following error when connecting:

Response received from device: NACK
Error: Address not acknowledged: 0x8FFF80C

I attached the full log of this connection here.

 

[maxschommer]

P.P.S.

I can't upload using the bootloader over UART either, I get a timeout in waiting for acknowledgement (for erasing internal memory sectors?) and write command not acknowledged, and then failed to download Sector[0] and then the file.

I attached the log.

[maxschommer]

I noticed that I am getting an NMI_Handler() error called in OPENBL_USART_WriteMemory() if I try to upload with "Skip flash erase before programming".

If I don't skip flash erase, I get a hardfault (screenshots of stack traces of both attached)

 

 

 

[maxschommer]

I figured out one thing which was going wrong and preventing me from being able to erase sector 0x08008000.

 

It turns out that even though I was following the video tutorial series about OpenBootloader and they said it was fine to put the user app at this address, it turns out that the compiled size of OpenBootloader for me was greater than 32kb, and so I was actually erasing some of the bootloader when I tried to load the user app. After turning on size optimization and getting the bootloader within 32kb so that none of it was written beyond the 0x08008000 boundary, I was able to successfully upload and verify code.

 

I am still having an issue jumping to the user app however, and am getting a hard fault when setting the main stack pointer to the user app address.

 

	/* Initialize user application's stack pointer */
	Common_SetMsp(*(__IO uint32_t*) Address);

[maxschommer]

Some more information:

 

I think the issue may be with the Common_SetMsp() function. I tried the following test:

I started debugging a program, and checked the stack pointer register in the "Registers" tab. The stack pointer was at 0x20044000. I then tried to use the Common_SetMsp(0x20044000) function, expecting it to cause no effect. Instead, it immediately entered a hard fault. If I try to set the stack pointer to a lower value such as 0x20043000 it works. Now this value (0x20044000) is the same one calculated by line in the OPENBL_FLASH_JumpToAddress function at the following line "*(__IO uint32_t*) Address" when the address is 0x08008000 (this is because *hopefully* I successfully uploaded a valid program at that address, so I would hope it's stack pointer is correct, which it seems to be).

 

void OPENBL_FLASH_JumpToAddress(uint32_t Address) {
	Function_Pointer jump_to_address;

	/* De-initialize all HW resources used by the Open Bootloader to their reset values */
	OPENBL_DeInit();

	/* Enable IRQ */
	Common_EnableIrq();

	jump_to_address = (Function_Pointer) (*(__IO uint32_t*) (Address + 4U));

	/* Initialize user application's stack pointer */
	Common_SetMsp(*(__IO uint32_t*) Address);

	jump_to_address();
}

 

My question is: Why does setting the stack pointer to something that is clearly a valid place for it to be, since I can see that the `sp` register is at that value when my program starts, cause a hard fault?

[maxschommer]

I noticed that I can only set the main stack pointer up to 108 bytes from the actual end of RAM before a hardfault is triggered. So I was successfully able to upload code when I just set the program's RAM to LENGTH = 270K instead of LENGTH = 272K in my linker script. I don't know why this is though, and it would be great to figure that out!