cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F070CBT6 jump to System Memory DFU

Alexander Frank
Associate II
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
18 REPLIES 18
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.

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
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);
Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
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.

Posted on December 08, 2016 at 19:24

I'm using the SPL, the examples I've built also have a ResetHandler method coded in assembler, been a couple of Cortex-M0 related threads, some of the links have broken in the migration to the new forum format

 

 
Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
Posted on December 09, 2016 at 10:51

Hi Alexander !

If you click on the first link that Clive provided you would see that the DFU bootloader seems to check the state of BOOT0, and that it may go back to your application. One of the workaround was to enable the BOOT0 pull-up before calling the DFU bootloader.

Mon2
Senior III
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.

Posted on December 12, 2016 at 06:59

Hi!

As in the Nucleo I'm using a 10k pull-down resistor. I'll have to try if the internal pull-up is enough to pull the signal high with the external pull-down.

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.
Posted on December 12, 2016 at 08:43

I checked yourcode and 'ported' it to the HAL.

/* 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();�?�?�?�?�?�?

Still no luck with jumping to the DFU.