2019-08-23 03:48 PM
Hi,
I'm developing bootloader on NUCLEO-F072RB board. I have ready bootloader code to jump for user application placed on specified address.
Now I'm writing this application so I'm changing this line in STM32F072RBTx_FLASH.ld file
FLASH (rx) : ORIGIN = 0x8000000, LENGTH = 128K
also I have remapped vector table into RAM.
After downloading user application into microcontroller I have noticed that program is in deed placed on specified location, but at the beginning of flash at the address 0x08000000 there are some bytes starting with "|ELF" string in ASCII and after that are zeros - it should be 0xFF's.
My bootloader application successfully jumps to that address and starts the program (I know that because I send some data on UART) but after a moment program hangs.
Can somebody help me with this case - basically I don't how to places all the program after specified address and left firsts sectors of flash left unprogrammed.
Thanks in advance, BR Daniel.
2019-08-23 04:09 PM
So how large is the bootloader?
The .LD for the bootloader should have
FLASH (rx) : ORIGIN = 0x8000000, LENGTH = 16K
The application
FLASH (rx) : ORIGIN = 0x8004000, LENGTH = 128K-16K
Have the linker generate .BIN files, examine. You shouldn't have an 0x7F,ELF signature at any location in memory
2019-08-23 04:21 PM
Hi Clive,
thank's for reply. Bootloader is small. I have FLASH (rx) : ORIGIN values in .LD file sets correctly.
Also I have cleared situation with with this ELF file in flash. You have to go to Project properties/C/C++ Build/Settings/MCU GCC Linker and in Xlinker add option -nmagic.
Now I'm only curious why user application hangs. I had add this relocation code at the beginning of main - without this user application will not start:
#define APPLICATION_ADDRESS 0x08004000
uint32_t i = 0;
uint32_t VectorTable[48];
for(i = 0; i < 48; i++)
{
VectorTable[i] = *(__IO uint32_t*)(APPLICATION_ADDRESS + (i<<2));
}
__HAL_RCC_SYSCFG_CLK_ENABLE();
__HAL_SYSCFG_REMAPMEMORY_SRAM();
Maybe is something wrong with this?
2019-08-23 05:57 PM
VectorTable would need to have an address of 0x20000000, the base of SRAM
You'd want to use your debugger, and follow the code execution, and make some determination about where it fails/hangs
2019-08-24 06:03 AM
How exactly set this vector table to this address?
I have made debugging my app.
When in debug mode app is bypasses bootloader and start executing directly from user application, and what is strange it hangs in different location.
Now program stop working here
__weak uint32_t HAL_GetTick(void)
{
return uwTick;
}
when I'm trying to get tick count.
EDIT:
I have removed get tick execution.
Now it is strange because when I'm going step by step with my app (debugging mode) app don't hang.
But when I'm Running app or using Step Return in debug it hangs in the same location as in when running with bootloader - on USART Transmit funcion.
2019-08-24 06:49 AM
uint32_t *VectorTable = (uint32_t *)0x20000000; // Base of SRAM used for vectors, and mapped to zero via SYSCFG Remapping
Not sure of the RAM size on your part, but advance the start of RAM visible to the linker, and shrink the size. This should leave that space free to use for the vector table. Would suggest doing for both loader and app. Usually the vector stuff is done in the main() of the App. Review some of ST's IAP examples.
RAM (xrw) : ORIGIN = 0x2000007C, LENGTH = 20K-0x7C
For interrupts, like SysTick to work, you'll need a properly configured VectorTable
2019-08-24 07:00 AM
Dear Clive,
huge help from you, everything is working now. Thank you very much, I own you a good bottle.
BR, Daniel