Issues in app after jump from bootloader CM3

Kernel
1

hackrid wrote on Tuesday, June 04, 2013:

Hi there,

i’m trying to jump from my FreeRTOS based bootloader to the FreeRTOS based main application.

The jump itself works. I can tell that from single stepping in the disassemlby. If I let the programm run, it soon enters the applications hardfault handler. It seems like the application crashes in early phases like zero init or low level init.

I’m struggling with this strange behvior for a few weeks now and could not get any further.
The only thing i noticed is, that the application executes correctly if i dont create tasks in the booloader.

I have allready tried to delete every task i created before the jump to the application but this does not change anything.

I’m also calling       taskENTER_CRITICAL() and   vTaskEndScheduler() before jumping to the application.

what point am i missing?

thank you very much for ANY help.
best regards

2

davedoors wrote on Tuesday, June 04, 2013:

Calling vTaskEndScheduler() will not do anything on a Cortex.

Are you remapping the vector table from the table used by your bootloader to the one used by your application?

Are you stopping the timer that generates the tick interrupts and clearing any pending interrupts before jumping to your application? Just disabling interrupts is probably not good enough because as soon as interrupts become enabled in your C start up code pending interrupts will execute but no longer have anything to execute because the bootloader is not running any more.

It might also be an idea to search the support archive as this topic has come up a few times before. http://www.freertos.org/FreeRTOS_Support_Forum_Archive/freertos_support_forum_archive_index.html

3

hackrid wrote on Tuesday, June 04, 2013:

hi,

thanks for your answer.

sure I’m remapping the vector table.
the main application and the jump to it does work, as long as i do not create tasks in the bootloader.

here is the code of the jump routine. is there something missing?

void vBootApplication(void)
{
   uint32_t u32JumpAddress;
   mg_DeInit();
   /* Disable all interrupts */
   RCC->CIR = 0x00000000;
   uint8_t tmp;
   /* Disable all interrupts */
   NVIC->ICER[0] = 0xFFFFFFFF;
   NVIC->ICER[1] = 0x00000001;
   /* Clear all pending interrupts */
   NVIC->ICPR[0] = 0xFFFFFFFF;
   NVIC->ICPR[1] = 0x00000001;
   /* Clear all interrupt priority */
   for (tmp = 0; tmp < 32; tmp++) {
       NVIC->IP[tmp] = 0x00;
   }
   NVIC_SetVectorTable(NVIC_VectTab_FLASH, 0x20000);
   /* Get jump address to application */
   u32JumpAddress = START_ADDR_OF_APPLICATION;
   u32JumpAddress = *(__IO uint32_t*) (START_ADDR_OF_APPLICATION + 4);
   Jump_To_Application = (mg_pFunction) u32JumpAddress;
   /* Initialize user application's Stack Pointer */
   __set_MSP(*(__IO uint32_t*) START_ADDR_OF_APPLICATION);
   /* Jump to application */
   Jump_To_Application();
}

I’ve searched a lot in the forums but could not find anything that brought me further. most people forgot to relovate the vector table. many of the found topics were not solved…

best regards

4

hackrid wrote on Wednesday, June 05, 2013:

i found it.

as soon as the scheduler starts to run, the process stack pointer is used.
as you can see, the MAIN stack pointer is loaded before the jump. but since the process stack pointer is used, strange behavior will occur.

now i have to fix this somehow….

but why is the used stackpointer not altered once the endScheduler is called?…. is this possibly a bug?

best regards

5

rtel wrote on Wednesday, June 05, 2013:

but why is the used stackpointer not altered once the endScheduler is called?…. is this possibly a bug?

From a previous post in this thread:

Calling vTaskEndScheduler() will not do anything on a Cortex.

Also note the first sentence on the documentation page:

http://www.freertos.org/a00133.html

and see the implementation of the function in the CM3 port:

void vPortEndScheduler( void )
{
	/* It is unlikely that the CM3 port will require this function as there
	is nothing to return to.  */
}

Regards.

6

hackrid wrote on Wednesday, June 05, 2013:

but should the vPortEndScheduler not change the used stack pointer back to msp ?

7

lorenzocorti wrote on Thursday, May 25, 2017:

I have the same problem, did someone find a solution?