Problem PB4 pin in iterrupt mode with bootloader custom for STM32F030C6

[u23]

Posted on September 26, 2014 at 15:29

Hi,

I configurated the PB4 pin in iterrupt mode,  every time you shoot the interrup the led is toggled. If the source code is compiled in start address 0x800 0000 it's ok, the interrupt it's ok and the led is toggled. If is compiled in start address 0x800 3000 and the firmware is uploaded with bootloader custom, the interrupt does not work. I tried to manage the PB4 pin in iterrupt mode in bootloader code and this works, only after loading the bootloader without application. Any idea? Thanks

[chen]

Posted on September 26, 2014 at 15:39

Hi

''If is compiled in start address 0x800 3000 and the firmware is uploaded with bootloader custom, the interrupt does not work.'' By default the boot vector (start address) for ST series of Cotex M3 is at 0x8000000 (or bit banded to 0x00000000) You cannot simply move your application to 0x8003000. You need to have another program (bootloader?) start your application. (BTW - what do you mean ''bootloader custom'' ? Is this the build into ROM DFU bootloader? Or your own custom  written Bootloader? )

[Tesla DeLorean]

Posted on September 26, 2014 at 16:25

The Cortex-M0 does NOT permit you to change the Vector Table Address, it's always at ZERO, and whatever is MAPPED there. Normally the base of FLASH, but can be configured to point to RAM.

The trick therefore is to carve out a section of RAM at the 0x20000000 base so the compiler/linker don't use it, and then COPY your vector table there, and MAP the base of RAM to ZERO.

[Tesla DeLorean]

Posted on September 26, 2014 at 16:29

int main(void)
{
int i;
uint32_t *p = (uint32_t *)0x20000000; // Base of RAM (0xC0 carved out in scatter file)
uint32_t *q = (uint32_t *)0x80000000; // Base of FLASH
/* 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 0x08000000) to the base address of the SRAM at 0x20000000. */
for(i=0; i<48; i++)
*p++ = *q++;
/* Enable the SYSCFG peripheral clock*/
RCC_APB2PeriphClockCmd(RCC_APB2Periph_SYSCFG, ENABLE);
/* Remap SRAM at 0x00000000 */
SYSCFG_MemoryRemapConfig(SYSCFG_MemoryRemap_SRAM);
// ...
while(1);
}

[u23]

Posted on September 29, 2014 at 08:46

I knowed the trick!

I have applicated this trick. All peripherals work except pin in iterrupt mode! P.S. For I written the bootloader!

[chen]

Posted on September 29, 2014 at 10:16

''I configurated the PB4 pin in iterrupt mode,  every time you shoot the interrup the led is toggled.

If the source code is compiled in start address 0x800 0000 it's ok, the interrupt it's ok and the led is toggled. If is compiled in start address 0x800 3000 and the firmware is uploaded with bootloader custom, the interrupt does not work.'' So, if the code is run from cold boot - it is OK. If the code is run after a custom boot loader, it is not OK. So what is the custom bootloader doing? How is it initialising the peripheral clock buses? How is it configuring the NVIC? A simple solution : in your application, reset all the peripheral buses,  peripherals and NVIC at start up. Best advice I can do without more time and info.

[u23]

Posted on September 29, 2014 at 11:11

The custom bootloader uses the uart peripheric for upload the application!

In the application the first operation is the initialization the peripherics. All the peripherics initialized is ok, except pin interrupt! I have tried to disable the all interrupts before jump in application, but not work. From: sung.chen_chungPosted: Monday, September 29, 2014 10:16 AMSubject: Problem PB4 pin in iterrupt mode with bootloader custom for STM32F030C6

''I configurated the PB4 pin in iterrupt mode,  every time you shoot the interrup the led is toggled.

If the source code is compiled in start address 0x800 0000 it's ok, the interrupt it's ok and the led is toggled. If is compiled in start address 0x800 3000 and the firmware is uploaded with bootloader custom, the interrupt does not work.'' So, if the code is run from cold boot - it is OK. If the code is run after a custom boot loader, it is not OK. So what is the custom bootloader doing? How is it initialising the peripheral clock buses? How is it configuring the NVIC? A simple solution : in your application, reset all the peripheral buses,  peripherals and NVIC at start up. Best advice I can do without more time and info.

[chen]

Posted on September 29, 2014 at 13:17

Hi

As I suggested : your bootloader is doing something to the configuration of the embedded processor that your application is not over riding. Carefully go through the start up code of the boot loader and check the configuration of : NVIC RCC GPIO EXTI registers. You may have to step through the code (since some of it is Library code from ST and you may not be aware of what it is doing).

[u23]

Posted on October 03, 2014 at 15:22

Hi,

I resolved! The solution consist in two operation: 1) Select the pin in port A, port B not work in interrupt mode with the bootloader + application; 2) Configure the EXTI peripheric in bootloader code and  in application code, else not work! UI