Booting firmware image through bootloader

And I also had given the isr addresses correctly, what happens is this.

I take a sample firmware with two simple counter tasks and boot it, that works.
And then I try the same with my actual firmware image(I changed the relevant isr addresses), but didn't modify stack or heap sizes in startup files nor in rtx_config file of firmware.

I hope I had made my doubts clear.

ChetaN

And I also had given the isr addresses correctly, what happens is this.

I take a sample firmware with two simple counter tasks and boot it, that works.
And then I try the same with my actual firmware image(I changed the relevant isr addresses), but didn't modify stack or heap sizes in startup files nor in rtx_config file of firmware.

I hope I had made my doubts clear.

ChetaN

Hi,

I didn't really get the point but perhaps this already helps:

I wrote Bootloader and Firmware as two completely independent applications (means, both can run alone), and linked the firmware to a higher address space, that does not get overwritten by the bootloader (in Flash).
I also have no RTX in Bootloader and RTX (and other RL components) in the FW.

Bootloader is @0x80000 size 0x10000
Formware is @0x90000 size 0x29000

I use the following code to jump into the firmware:

#define NVIC_VectTab_FLASH       0x90000    // FW is linked to Flash Base 0x90000
#define SP_OFFS                     0
#define RESET_OFFS                  4

int main()
{
  void (*user_code_entry)(void);
  register uint32_t MSP __ASM("msp");

  // Bootloader code, i.e. look for new FW on SD Card and flash it
  ....

  SCB->VTOR       = NVIC_VectTab_FLASH;
  user_code_entry = (void (*)(void))(( *((unsigned int *)(NVIC_VectTab_FLASH + RESET_OFFS))) );
  MSP             = *((unsigned int *)(NVIC_VectTab_FLASH + SP_OFFS));

  user_code_entry();  // starts Reset Vector from FW

  while(1); // should never reach this...
}

I hope this helps.

BR,
/th.

If you have any Interrupts enabled, they must be disabled before reconfiguring the VTOR.

Thanks Buhr.

But I have one more to do, that is firmware is compiled with the BASE address as 0x00. And this image is given to bootloader which then writes it in flash memory starting at 0x1a020020.

And then it boots, doing some non-RTX related initialization. When os_sys_init(init_task) is called, it's not going into init_task function. I think this is due to improper svc_handler(initialization for RTX functionality when os_sys_init(init_task) called) mapping.

So, what could be done to overcome this?

The trick is to understand the requirements of the Cortex-M3, and come up with a plan that meets those instead of the odd plan you have contrived.

You need to compile/link you firmware at the address it is going to run at, not something packaged up with headers. The base of the image needs the vector table, or you need to copy the table into RAM and point the VTOR register at it. The vector table typically needs to fall on a 512/1024 boundary depending on it's size. If you must burn the header in flash, consider making it a size that matches the boundary conditions.

Thorsten's method works a lot better, because he understands what the processor expects. You'd do well to review it, and the TRM's for the part.

Thanks Pier.

I actually wanted to know about the stack size for the tasks created in firmware, because size of stack for task is what posing a problem in my case,rest of it is okay from the beginning. I mean the total application is working well.

The thing is that I have added much code in the tasks which, as far I could understand, need more stack size. But I couldn't get how much this size should be in these tasks. I can't try just by going on increasing stack size. This was my actual problem. And regarding previous doubts, they're well cleared by Thorsten.

I'd be thankful if you could suggest any method for this stack size.

Hi,

afaik there is no "magic weappon" finding the proper stack size as investigating your code.
Our RTX does a stack check, it looks if the magic word it writes to the stack ends has been overwritten.

You know, that in RTX you can set the generic stack size, but you can also create tasks with a user defined RAM area as stack?

A good method would be that you manually fill your RAM with a pattern you can identify, and let your program run for a while. Then stop and read all the memory (you must find the task stacks, that can be a bit more tricky ...).
After that you can see how much stack each task needs...

If you have no recursive function calls, it should be possible that you calculate the worst case stack through your function calls.

Thanks again!

I'll try this.