STM32F070CBT6 jump to System Memory DFU

[Alexander Frank]

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

[Mon2]

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.

[Tesla DeLorean]

Posted on December 12, 2016 at 16:26

After you map the ROM to zero, you can use that as the basis

SysMemBootJump = (void (*)(void)) (*((uint32_t *) 0x00000004)); // Point the PC to the System Memory reset vector (+4)

SysMemBootJump();

Also you don't set the MSP to the ROM address, it will be useless as a stack, it is the content at that address you need to read

__set_MSP(*((uint32_t *) 0x00000000)); // Read the Initial SP

__set_MSP(0x20002000); // or use some address in SRAM that is viable for a stack

[Alexander Frank]

Posted on December 13, 2016 at 08:04

By the way: The STM32F070xB/6 have a dedicated BOOT0 pin. I think it's not possible to enable a pull-up.

But because I can't even enter the Bootloader on the NUCLEO-F070RB when connecting the BOOT0 pin with 3.3V I think there's another problem.

[Alexander Frank]

Posted on December 13, 2016 at 08:31

Thanks. But still no luck.

void (*SysMemBootJump)(void);
void SystemInit(void)
{
if ( *((unsigned long *)0x20003FF0) == 0xDEADBEEF ) {
*((unsigned long *)0x20003FF0) = 0xCAFEFEED; // Reset our trigger
/* Enable the SYSCFG peripheral clock*/
//RCC_APB2PeriphClockCmd(RCC_APB2Periph_SYSCFG, ENABLE);
RCC->APB2ENR |= RCC_APB2ENR_SYSCFGCOMPEN;
/* Remap ROM at 0x00000000 */
//SYSCFG_MemoryRemapConfig(SYSCFG_MemoryRemap_SystemMemory);
__HAL_SYSCFG_REMAPMEMORY_SYSTEMFLASH();
__set_MSP(*((uint32_t *) 0x00000000)); // Read the Initial SP
SysMemBootJump = (void (*)(void)) (*((uint32_t *) 0x00000004)); // Point the PC to the System Memory reset vector (+4)
SysMemBootJump();
while (1);
}
...�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?

If I run it in the debugger the program seems to be stuck in__set_MSP.

If I look in the Disassembly itseem to be stuck in a loop.

[Tesla DeLorean]

Posted on December 13, 2016 at 16:00

Ok, but can you identify what loop?

What value is it loading into the MSP?

Are you running an RTOS, do you have interrupts running that might vector off to odd places?

Instrument your code with printf()'s to a USART so you can understand values being loaded, and flow.

[Mon2]

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

[Mon2]

Posted on December 14, 2016 at 00:06

Clive !! How are you ? Just a quick shout out to you - we worked together (you and Ron P.) on some add-on adapters when you were with Micro Solutions (ST78C36 EPP host adapter). Glad to see you here and honored that you are assisting others with your wealth of knowledge ! Our company is still chugging along with many new designs for the add-on market (PCIe, USB 2.0, USB 3.x and some pending optical designs). Bye for now.

Kumar

[Alexander Frank]

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.

[NT.3]

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();

}