wtywtykk

Forum Replies Created

Viewing 5 posts - 16 through 20 (of 20 total)
  • Author
    Posts
  • in reply to: BIN file size ecxeeds flash size with no error #24244
    wtywtykk
    Participant

    Hi,

    I’m sorry. I just forgot the fact that I can just put the code here…. The code is based on the LEDBlink project for stm32f030f4.

    #include <stm32f0xx_hal.h>
    #include <stm32_hal_legacy.h>
    
    const uint8_t Large_Const_Array[1024 * 13 + 256] = { 0 };
    uint8_t Large_Nonconst_Array[2000] = { 0x00,0x01,0x03,0x04,0x05 };
    
    #ifdef __cplusplus
    extern "C"
    #endif
    void SysTick_Handler(void)
    {
    HAL_IncTick();
    HAL_SYSTICK_IRQHandler();
    }
    
    int main(void)
    {
    HAL_Init();
    
    __GPIOC_CLK_ENABLE();
    GPIO_InitTypeDef GPIO_InitStructure;
    
    GPIO_InitStructure.Pin = GPIO_PIN_12;
    
    GPIO_InitStructure.Mode = GPIO_MODE_OUTPUT_PP;
    GPIO_InitStructure.Speed = GPIO_SPEED_HIGH;
    GPIO_InitStructure.Pull = GPIO_NOPULL;
    HAL_GPIO_Init(GPIOC, &GPIO_InitStructure);
    
    uint32_t i = 0;
    for (;;)
    {
    HAL_GPIO_WritePin(GPIOC, GPIO_PIN_12, GPIO_PIN_SET);
    HAL_Delay(500);
    HAL_Delay(Large_Const_Array[(i++) % sizeof(Large_Const_Array)]);//Just prevent the array from being optimized out
    HAL_GPIO_WritePin(GPIOC, GPIO_PIN_12, GPIO_PIN_RESET);
    HAL_Delay(500);
    HAL_Delay(Large_Nonconst_Array[i % sizeof(Large_Nonconst_Array)]);//Just prevent the array from being optimized out
    }
    }

     

    • This reply was modified 6 years, 10 months ago by support. Reason: formatting
    in reply to: BIN file size ecxeeds flash size with no error #24217
    wtywtykk
    Participant

    Hi,

    The variables aren’t optimized away or placed into a different section. Normally they are placed after the code and copied to sram by a for loop in the Reset_Handler. But in this case, they are simply placed outside the flash because there are no room left.

    It turns out that the original linker script makes the linker unware of the size needed for the initial value area. From the report by objdump, no section is assigned for them, and the linker simply put all the data after the address that symbol “_sidata” points to.

    The solution I found is changing the data section description in the linker script to

    .data :
    {
    . = ALIGN(4);
    _sdata = .;

    PROVIDE(__data_start__ = _sdata);
    *(.data)
    *(.data*)
    . = ALIGN(4);
    _edata = .;

    PROVIDE(__data_end__ = _edata);
    } > SRAM AT > FLASH

    Note that the “AT” at the first line is removed and the “AT > FLASH” at the last line is added.

    PS: I doesn’t have a board to test this fix for now. But I checked the symbols and sections with objdump, and it seems to work. The linker also shows an error message if the flash isn’t large enough.

    PPS: May be the there are still some problems with the ALIGN statements. It’s not fully tested.

    wtywtykk
    Participant

    Also, “config.h” can no longer generated automatically. VisualGDB adds a reference into the project, but the file itself is not generated.

    in reply to: Poor performance with MSP430F5529 launch pad #12522
    wtywtykk
    Participant

    Hi,

    I’m quite surprised. The “-break-insert -f main” command causes the problem. If I run it before “load”, gdb will break the program into really small pieces and then download them one by one. And if I run “load” before “-break-insert -f main”, there’s no problem.

    So I tried to add “-break-delete 1” in the “Additional GDB Commands” tab to remove this break point before download. It works,but is there any side effect?

    in reply to: Poor performance with MSP430F5529 launch pad #12516
    wtywtykk
    Participant

    The debugger on the launchpad is eZ-FET lite. I’m not sure whether it’s related.

Viewing 5 posts - 16 through 20 (of 20 total)