Hello All,
my goal is to use the OpenBLT Bootloader on a STM32F103C6 to flash and later update a Keil RTX project.
The bootloader part (OpenBLT with UART Interface) is using the space between 0x08000000 to 0x08001800 on ROM and 0x20000000 to 0x20000C00 on RAM.
The RTX Application is unsing a scatter-file to create the file for flashing with the OpenBLT:
; ************************************************************* ; *** Scatter-Loading Description File for OpenBLT *** ; ************************************************************* LR_IROM1 0x08001800 0x00005800 { ; load region size_region ER_IROM1 0x08001800 0x00005800 { ; load address = execution address *.o (RESET, +First) *(InRoot$$Sections) .ANY (+RO) } RW_IRAM1 0x20000C00 0x00001C00 { ; RW data .ANY (+RW +ZI) } }
As described in the OpenBLT guide, the "Checksum placeholder" is placed at the end of the vector table of the RTX Project (startup_stm32f10x_ld.s):
... DCD 0 ; Reserved DCD EXTI15_10_IRQHandler ; EXTI Line 15..10 DCD RTCAlarm_IRQHandler ; RTC Alarm through EXTI Line DCD USBWakeUp_IRQHandler ; USB Wakeup from suspend DCD 0x55AA11EE ; OpenBLT Checksum Reserved place __Vectors_End
The BOOT_FLASH_VECTOR_TABLE_CS_OFFSET is set to 0x130 in the flash.c file.
When I try to flash an RTX-like Project, the application is calling immediately the _sys_exit() function. (I'm using the
#pragma import(__use_no_semihosting)
and have implemented the function to get over the BKPT 0xAB).
When I try to flash an non-RTX Project, the application is running fine.
I think, that the problem is somewhere in the initializing code of the RTX kernel, maybe some Stack or Heap related part, but I really don't know where to start, because debugging is only possible when running the OpenBLT application and then following the program in the disassembly window...
Unfortunately I havent found a OpenBLT example who includes an Keil RTX program to run, only non-RTX examples.
Thanks
Alain
Try these in conjunction with what Robert #1 suggested.
1) See that your RTX_Config.c file is configured properly. Make sure you are looking at the EXACT one that is being used.
2) Look in the map file and see how much space is allocated for mp_tcb, mp_stk, os_stack_mem and make sure it matches what your RTX_Config.c files thinks they should be.
3) For a test, build a scatter file for the APP that loads at 0x08000000, rebuild and overwrite the bootloader and see if this runs properly or not.
An item of interest is that the Bootloader seems to set the stack to the highest RAM address as opposed to something within the range of 0x20000000 and 0x20000C00. Probably not your issue, but if you are really intending to keep these 2 separate, they are not.
It looks as if the memory for task control block could not be allocated. This should normally not occur since the memory is provided statically by the kernel.
Yes it is not something that occurs on its own, but it is only "semi" statically allocated. It can be set to 0 (i.e. it is possible that this is "empty" or "has no items" in it, but the compiler will not tell you that (so not quite statically allocated). As it seems that the rt_alloc_box for the STACKS may also be failing, maybe it is also zero or something else is wrong but related what makes the rt_alloc fail for both the TCB and Stack area's.
Even if the main thread could not be created, the function osKernelStart() should not return but switch to the Idle task which is created implicitly during osKernelInitialize().
Yes and I am not seeing any reason to believe that it not being scheduled and dispatched. It would seem that it is probably the only thread the system thinks it has. The TCB for the idle thread is statically allocated (it is REALLY statically allocated such that if it compiles space for it will exist). My guess is the rt_alloc for the stack for the Idle thread is failing, and this causes it to be set to 0. When the initial stack frame is generated and the stack adjusted, it will not actually be pointing to or set to anything valid. I believe the hard fault comes when the system "returns" to the idle thread.
I suggest you debug further and check first osKernelInitialize() and then osKernelStart().
And remember (or note) you can add the source code to the os to your application and it will allow you to do source level debugging of your app including the os. (just make sure that after you add the files, you select do not include in build)
You could take a look at existing examples (Blinky) found in the Device Family Pack for STM32F1 (http://www.keil.com/dd2/pack/).
Yes, the blinky examples are always great.