STM32F072 DFU vs. App

[anagy9]

Posted on April 18, 2015 at 23:21

Hi All,

I'm new on STM controllers and I don't know enough about this controller yet. I tried to use USB DFU on Discovery board. I using latest DfuSe 3.0.4 and latest STM32Cube_FW_F0_V1.2.0\Projects\STM32F072B-Discovery\Examples\GPIO\GPIO_IOToggle If I upload this example by STLink it works as expected. If I change IROM1 to 0x8007000 0x19000 in this example, recompiled and uploaded by DFU then the LD3 lit up only. I found that the App is working but the HAL_Delay() function doesn't. Finally I found that the uwTick variable does not incremented by SysTick handler. If I replaced HAL_Delay by a long For-loop it worked perfectly. Does anybody know why? What I'm missing? Thank you so much! Attila #keyhole-debugging #stm32f072b-discovery-b #usb-dfu

[Tesla DeLorean]

Posted on April 19, 2015 at 01:49

The SysTick interrupt probably isn't working because if you change the base address of the image you would need to copy the new Vector Table into RAM, and map the RAM at ZERO.

The Cortex-M0 does not provide a programmable Vector Table address register.

[anagy9]

Posted on April 19, 2015 at 10:34

Hi,

Thank you for your answer! Initialization of this example code does not make this table? How can I do that?

[Tesla DeLorean]

Posted on April 19, 2015 at 16:16

In the SPL, we'd do it like this.

[DEAD LINK /public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/STM32F051K6%20NVIC_SetVectorTable&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=59]https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/STM32F051K6%20NVIC_SetVectorTable&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B¤tviews=59

[anagy9]

Posted on April 19, 2015 at 19:23

So it means I have to move Toggle example to IAP template? (because Cube FW does not contain SysConfig and RCC_APB2PeriphClockCmd functions)

[Tesla DeLorean]

Posted on April 19, 2015 at 22:45

So it means I have to move Toggle example to IAP template? (because Cube FW does not contain SysConfig and RCC_APB2PeriphClockCmd functions)

No, I just think it means that you need to understand enough about your chosen processor and tools to fashion something equivalent.

[anagy9]

Posted on April 21, 2015 at 19:04

Ok, I read the AN4065, RM0091 Physical remap section (pg53) and added this code to GPIO_Toggle example:

#define RCC_APB2Periph_SYSCFG RCC_APB2ENR_SYSCFGEN
#define APPLICATION_ADDRESS (uint32_t)0x08007000
#if (defined ( __CC_ARM ))
__IO uint32_t VectorTable[48] __attribute__((at(0x20000000)));
#elif (defined (__ICCARM__))
#pragma location = 0x20000000
__no_init __IO uint32_t VectorTable[48];
#elif defined ( __GNUC__ )
__IO uint32_t VectorTable[48] __attribute__((section(''.RAMVectorTable'')));
#endif
void RelocateNVICTable() {
/* Relocate by software the vector table to the internal SRAM at 0x20000000 ***/
/* Copy the vector table from the Flash (mapped at the base of the application
load address 0x08007000) to the base address of the SRAM at 0x20000000. */
for(int i = 0; i < 
48
; i++)
{
VectorTable[i] = *(__IO uint32_t*)(0x08007000 + (i<<2));
}
/* Enable the SYSCFG peripheral clock*/
RCC->APB2RSTR |= RCC_APB2Periph_SYSCFG;
/* Remap SRAM at 0x00000000 */
//SYSCFG_MemoryRemapConfig(SYSCFG_MemoryRemap_SRAM);
SYSCFG->CFGR1 = SYSCFG_CFGR1_MEM_MODE_1 | (SYSCFG->CFGR1 & (~SYSCFG_CFGR1_MEM_MODE));
}
int main(void)
{
RelocateNVICTable();
... 

And of course changed the linker settings:

IROM1: 0x08007000

0x19000

IRAM1: 0x20000000 0xC0 IRAM2: 0x200000C4 0x1F40 But it still not working. TheuwTick is not incrementing. What am I missing?

[Tesla DeLorean]

Posted on April 21, 2015 at 19:34

You want to enable the clock, not reset the peripheral

/* Enable the SYSCFG peripheral clock*/

RCC->APB2ENR |= RCC_APB2Periph_SYSCFG;

[anagy9]

Posted on April 21, 2015 at 21:14

Unfortunately it is not solved the issue. There should be something more...

If I run FW in debug mode I can see that the vectors are copied to SRAM from 0x20000000. But uwTick still not incremented :(

[Tesla DeLorean]

Posted on April 21, 2015 at 22:24

Yeah, I have a very narrow view of the problem, possessing neither the hardware or the software.

You should check you can see them at 0x00000000, and then confirm that the SysTick interrupt is enabled somewhere, and the address of the SysTick_Handler matches the value in the vector table.