[STM32 USB training - 11.3 USB MSC DFU host labs] Does the current code not fit?

[#1]

Hello,

I'm trying to reproduce this tutorial:

[STM32 USB training - 11.3 USB MSC DFU host labs]

https://www.youtube.com/watch?v=CGUC1wqSLCE

(Note: The original code is available in the video description)

I'm not able to make the final code run (flashing the led, lit for 100ms).

After trying to manually load using ST-Link, I noticed that the code size of the first program is larger than the flash range between 0x0800000 and 0x08007FFF.

This program reads the image.bin file from the USB flash drive and writes the contents of the image.bin file from the address 0x08008000 of the flash memory.

Apparently this first part works, but it no longer fits inside the 2 sectors (32K; 0x8000) that were initially reserved to operate as a bootloader.

When looking at the original code, using the STM32CubeProgrammer, we see that this code has only 0x610C (ie it is below 0x8000).

The code generated in release mode in STM32CubeIDE 1.9.0 has the size: 0x8040.

I tried to disable the USB debug and the serial port, but even then in debug mode the code is still this size: 0xB930. Only in release mode it has this usable size: 0x5F0C.

I'm commenting that if someone tries to reproduce this tutorial, it may no longer work just using 32K initials.

I believe this is not a BUG, but it would be very interesting if there was a way to select a Bootloader mode to be able to make the DFU code smaller, perhaps fitting into just one sector (16K), instead of having to use more memory for bootloader.

 

 

 

[#2]

I'm not able to make the final code run (flashing the led, lit for 100ms).

Solution:

HAL_RCC_DeInit();
JumpAddress = *(__IO uint32_t*) (APPLICATION_ADDRESS + 4);
Jump_To_Application = (pFunction) JumpAddress;
SCB->VTOR = APPLICATION_ADDRESS;
__set_MSP(*(__IO uint32_t*) (APPLICATION_ADDRESS ));
Jump_To_Application();

https://community.st.com/s/question/0D53W00001ZYYwWSAX/stm32cubeide-190-deinitialization-of-peripherals-doesnt-seem-to-work

[#3]

After I managed to make the led blink, I tried to adapt another older code, which uses several peripherals, and there was no problem, I just changed the FLASH address as indicated in the tutorial:

[STM32 USB training - 09.9 USB DFU device labs]

https://www.youtube.com/watch?v=n_LDXOQHerU

 File STM32F407VGTX_FLASH.ld

FLASH (rx) : ORIGIN = 0x8008000, LENGTH = 1024K - 2*16K

File stm32f407xx.h

#define FLASH_BASE 0x08008000UL

But this code already had the Flash CRC implemented, so I managed to generate add the CRC code with this command:

srec_cat FIRM1.hex -Intel -fill 0xFF 0x08000000 0x080FFFFC -crop 0x08000000 0x080FFFFC -STM32 0x080FFFFC -o ROM1.hex -Intel

I don't know if there's another way to do this, maybe it's possible to just use the STM32 itself to record the CRC calculation on its own instead of using the SREC_CAT program, let's say that when starting the STM32 it still has a default value of 0xFF and then the STM32 itself saves the CRC value that it calculated itself.

Anyway, I did it this way to test:

• I burned the bootloader similar to the tutorial with USB Host and the LED that blinks.

• I started STM32, it found the image.bin file and burned it in itself.

• Using the STM32CubeProgrammer program, I read all of Flash (I still didn't have the CRC code saved at the end of Flash, so my old program complained about CRC failure)

• Then I ran the command quoted above with srec_cat

• I used STM32CubeProgrammer again to test, burned the new file generated by srec_cat, and it worked.

Where FIRM 1.hex is the file saved by the STM32CubeProgrammer, and the file ROM1.hex is the final file, which was burned in the STM32.

Reference on the implementation of the CRC:

https://community.st.com/s/question/0D53W00001Z9UUUSA3/bug-why-is-the-ide-190-preventing-hex-file-selection-instead-of-elf