0
\$\begingroup\$

My problem is that my bootloader is not jumping to the application, or maybe it is but then jumps back to the bootloader because of an interrupt. To give you something to work with here are some info:

The code that jumps to the application

typedef void (*pFunction)(void);

pFunction Jump_To_Firmware;

void JumpToInternalFlashImage()
{
    Jump_To_Firmware = (pFunction) (*(uint32_t *)(0x08008000 + 4));

    __set_MSP(*(uint32_t*) 0x08008000);

    Jump_To_Firmware();

}

How main looks in the application

int main(void)
{
    // Copy ISRs to RAM
    memcpy((uint8_t *)&_isr_vector_ram_start, (uint8_t *)&_isr_vector_flash_start, &_isr_vector_flash_end - &_isr_vector_flash_start);

    // Relocate the vector table
    SCB->VTOR = (uint32_t) &_isr_vector_ram_start;

    HAL_Init();

    SystemClock_Config();

    MX_GPIO_Init();
    MX_DMA_Init();
    MX_USART2_UART_Init();

    while (1)
    {
        HAL_UART_Transmit_DMA(&huart2, "hello", 5);

        uint32_t i =0;
        for(;i<1000000;i++);
}

It should perhaps be pointed out that this program works fine if I program it through ST link without any bootloader code. Also the important parts of this code should be the first lines where I copy the ISRs to RAM and then relocate the vector

The linkerscript looks like the following to give you an idea of where the addresses come from ( it looks the same in both bootloader and application )

/* Entry Point */
ENTRY(Reset_Handler)

/* Highest address of the user mode stack */
_estack = 0x20050000;    /* end of SRAM2 */

/* Generate a link error if heap and stack don't fit into RAM */
_Min_Heap_Size = 0;      /* required amount of heap  */
_Min_Stack_Size = 0x400; /* required amount of stack */

// There are more areas but these should be the only relevant ones
MEMORY
{
   FLASH (rx)      : ORIGIN = 0x08000000, LENGTH = 1024K
   RAM_ISR (xrw)   : ORIGIN = 0x20000000, LENGTH = 512
   RAM (xrw)   : ORIGIN = 0x20000200, LENGTH = 64K - 512
}

SECTIONS
{
    /* The startup code goes first into FLASH */
    .isr_vector :
    {
        . = ALIGN(4);
        _isr_vector_flash_start = .;
        KEEP(*(.isr_vector)) /* Startup code */
        _isr_vector_flash_end = .;
        . = ALIGN(4);
    } >FLASH

   ._isr_vector_ram (NOLOAD) :
   {
       . = ALIGN(4);
       _isr_vector_ram_start = .;
       KEEP(*(._isr_vector_ram)) /* Startup code */
       . = ALIGN(4);
   }>RAM_ISR
}

So my problem is that when I try to jump to the application it doesn't work

The first addresses from 0x8008000 ( application start address ) looks like

enter image description here

And at the address 0x08004DD1 it looks like

enter image description here

What happens is that I always end up stuck when the program counter points at(it does not move from this address when trying to step further )

0x8007770

and MSP

0x2004ffe0

in the output.map for the bootloader I can see that 0x08007770 is

.text.Default_Handler
            0x08007770        0x2 startup/startup_stm32f746xx.o
            0x08007770                RTC_Alarm_IRQHandler
            0x08007770                EXTI2_IRQHandler
            0x08007770                TIM8_CC_IRQHandler
            0x08007770                DebugMon_Handler
            0x08007770                UART8_IRQHandler
            0x08007770                SPI4_IRQHandler
            0x08007770                TIM1_CC_IRQHandler
            0x08007770                DMA2_Stream5_IRQHandler
            0x08007770                HardFault_Handler
 and so on (the rest of the handlers )

Does anyone know what my problem is and how to solve it ? Please feel free to ask questions if you feel like I've missed to tell you something

\$\endgroup\$
  • \$\begingroup\$ Shouldn't i be declared volatileto avoid the loop being removed by the compiler's optimiser? \$\endgroup\$ – Peter Mortensen Jan 16 '17 at 0:48
0
\$\begingroup\$

You should adjust your linker scripts to reflect the fact that the programs are to be loaded to separate flash areas. So, for the bootloader you need

FLASH (rx)      : ORIGIN = 0x08000000, LENGTH = 32K

and for the application:

FLASH (rx)      : ORIGIN = 0x08008000, LENGTH = 992K /* (992 = 1024 - 32 */
\$\endgroup\$
  • \$\begingroup\$ Thanks, this actually changed things. It doesn't work yet but what happens what I do this is that the address that in the pictures is 0x08004DD1 changes to 0x0800CDCD and when I go to that address it's empty. Meaning that there's no data from that address. Any ideas of what causes that ? When programming I'm simply using a start address and then incrementing with 4 bytes until the entire bin file is programmed \$\endgroup\$ – user3660570 Jan 12 '17 at 9:40
  • \$\begingroup\$ If the address is empty, then something is wrong with the flashing process, or the bin file got truncated, I'd first debug that issue. Also note that the actual instruction address is one less than the pointer value. \$\endgroup\$ – berendi Jan 12 '17 at 12:11
  • \$\begingroup\$ The thing is that my solution to copy the ISR vector memcpy((uint8_t *)&_isr_vector_ram_start, (uint8_t *)&_isr_vector_flash_start, &_isr_vector_flash_end - &_isr_vector_flash_start); is based of the start -and endaddress of flash. Is this really happening after I changed the memoryarea ? \$\endgroup\$ – user3660570 Jan 12 '17 at 12:29
  • 1
    \$\begingroup\$ I've noticed that if I program the app through ST-Link and choose startaddress 0x08008000 it works and no code seams to be missing at the address I pointed out earlier. But I am unsure of where the problem might be. Because all the data from the bin file seams to be in the flash when I use the bootloader, yet it is clear that data is missing on the memory addresses. Do you know if ST-Link does anything special other than just copying the BIN file to flash ? \$\endgroup\$ – user3660570 Jan 12 '17 at 15:08
  • 1
    \$\begingroup\$ Solved the issue. It was indeed the flashprogramming that failed because of overflowing buffers. The linkerscript could be either 0x08008000 or 0x08000000 but I'll mark this as the correct answer anyway \$\endgroup\$ – user3660570 Jan 13 '17 at 13:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.