Skip to main content
Visitor II
December 8, 2016
Question

STM32F070CBT6 jump to System Memory DFU

  • December 8, 2016
  • 4 replies
  • 3788 views
Posted on December 08, 2016 at 17:50

I'm trying to jump from an application to the DFU

System Memory Bootloader.

According toAN2606 this should work with my processor and the System Memory should start at address0x1FFFC800.

I'm using an external clock (HSE) with 16MHz.

I'm using CDC with CubeMX which is working as expected.

For testing I want to jump to the DFU Bootloader when receiving someting via CDC.

I found

http://stackoverflow.com/a/28288454

some code how this should work.

In myCDC_Receive_FS function I'm preparing the jump to the bootloader by setting avalue in the RAM and checking this value in SystemInit function:

// 16k SRAM in address 0x2000 0000 - 0x2000 3FFF

*((unsigned long *)0x20003FF0) = 0xDEADBEEF;

// Reset the processor

NVIC_SystemReset();

I changed the SystemInit function

void (*SysMemBootJump)(void);

void SystemInit(void)

{ if ( *((unsigned long *)0x20003FF0) == 0xDEADBEEF ) { *((unsigned long *)0x20003FF0) = 0xCAFEFEED; // Reset our trigger __set_MSP(0x1FFFC800); //__set_MSP(0x20002250); SysMemBootJump = (void (*)(void)) (*((uint32_t *) 0x1FFFC804)); // Point the PC to the System Memory reset vector (+4) SysMemBootJump(); while (1); }

When I'm sending something via CDC with the PC I can see in the debugger the function

SysMemBootJump is called.

But after that Windows does not detect the DFU device.

In the dissassembly I can see this:

1fffe6c4: str r2, [r3, #0]

1fffe6c6: ldr r4, [r0, #0] 1fffe6c8: cmp r4, r1 1fffe6ca: beq.n 0x1fffe6c4

Any suggestions?

Thanks

#dfu #system-memory
    This topic has been closed for replies.

    4 replies

    Graduate II
    December 8, 2016
    Posted on December 08, 2016 at 18:16

    You'd have to make sure you map the ROM back at the zero basis so the vector table and interrupts will work correctly.

    Graduate II
    December 8, 2016
    Posted on December 08, 2016 at 18:20

    Not using your part, something along these lines

    /* Enable the SYSCFG peripheral clock*/

    RCC_APB2PeriphClockCmd(RCC_APB2Periph_SYSCFG, ENABLE);

    /* Remap ROM at 0x00000000 */

    SYSCFG_MemoryRemapConfig(SYSCFG_MemoryRemap_SystemMemory);
    Visitor II
    December 8, 2016
    Posted on December 08, 2016 at 18:54

    Thank you.

    I'll have to check what to change for my controller.

    RCC_APB2Periph_SYSCFG and SYSCFG_MemoryRemap_SystemMemory are undeclared.

    Visitor II
    December 11, 2016
    Posted on December 11, 2016 at 05:35

    I'm using an external clock (HSE) with 16MHz.

    See AN2606 - Section 9 for the STM32F070xB devices bootloader details.

    0690X00000605RcQAI.png

    Not 100% sure this is your issue but worth a review. Hope to know more next week when we test the same concepts of the USB interface using the STM32F070 target. Assorted users are reporting issues with using the STM32F070 (present on the Nucleo) while strapping BOOT0 to Vdd and receiving an ''Unknown Device'' in the Device Manager (Windows) - while the STM32F070F6P6 (20 pin TSSOP) is working. In both cases, 8 mhz was used as an external clock permit USB to be clocked as required.

    Visitor II
    December 12, 2016
    Posted on December 12, 2016 at 07:08

    0690X00000605k4QAA.png

    Thanks, I also saw 16MHz missing on the page but one page later ST writes 16 MHz is valid for DFU. 

    I also had the problem you described with the Nucleo-F070RB. Using Vcc on BOOT0 pin did not lead to DFU mode. I also got a 

    ''Unknown Device'' in the Windows Device manager but I thought it's a problem with my Nucleo.

    I tried the same thing with a Nucleo-L4...

    (I don't know the exact identification)

     (NUCLEO-L476RG) and it worked there without a problem.
    Visitor II
    December 12, 2016
    Posted on December 12, 2016 at 14:26

    Try jumping to: 0x1FFFC400

    and found the following details for the STM32F070x6 which may also be worth testing:

    Note:User can jump to the System Memory Bootloader from his application code using the following entry point: 0x1FFFC518.

    so please also attempt a call to the entry point of 0x1FFFC518.

    Visitor II
    December 13, 2016
    Posted on December 14, 2016 at 00:02

    Please review my last post here - believe your issue is related. Summary - the boot loader is defective on earlier silicon releases of the STM32F070 devices. Welcome the details of your ROM version to nail this down. ST is assisting in reviewing which date codes of the silicon are affected.

    https://community.st.com/0D70X000006SYzFSAW

     

    Tomorrow we will investigate the 20 pin TSSOP package with hopes the ROM based DFU bootloader operates correctly so we can proceed with our project

    Visitor II
    January 16, 2017
    Posted on January 16, 2017 at 10:13

    I gave up using the System Memory DFU. I'm using now an UART IAP which I program in the flash.

    Thanks for your help.

    Visitor II
    September 11, 2023

    6 years laters I couldn't find any examples for the F070CB. So as I got the jump to bootloader working here it is:

     

    void jump_bootloader()
    {
    void (*SysMemBootJump)(void);
    volatile uint32_t addr = 0x1FFFC800;

    HAL_RCC_DeInit();

    SysTick->CTRL = 0;
    SysTick->LOAD = 0;
    SysTick->VAL = 0;

    SysMemBootJump = (void (*)(void))(*((uint32_t *)(addr + 4)));
    __set_MSP(*(uint32_t *)addr);
    SysMemBootJump();
    }