µTasker Forum > ST^TM STM32 and STR91XF

STM32 uTaskerBoot Project

<< < (2/4) > >>

TeeYi:
Hi Mark,
    I try to use uTaskerCombine tool to combine the uTaskerBoot.bin (from uTaskerBoot Project) with uTakserBM.bin (from uTaskerV1.4 Project) as below: (STM32)

   uTaskerCombine uTaskerboot.bin uTaskerBM.bin 0x1000 STM32.bin STM32.out 0x80000000

and 

   uTaskerCombine uTaskerboot.bin uTaskerBM.bin 0x1000 STM32.bin

but both command only generated STM32.bin file with 0 byte size.


    I attached both file for your reference & testing. Please advice how to generate the .out format file that required by IAR to program the firmware into the STM32 MCU.
    I am using Window 7 Professional (64bit) & uTaskerCombine V1.6 .

     Thanks.
     Tee
     
       
   

mark:
Hi

When this command is executed there is the message "Boot code too long (> 1000). Terminating" and so no output content is generated.
The problem is that the "uTaskerBoot.bin" is 50k in size and the command tried to add the second file "uTaskerBM.bin" at the location 0x1000, which is not possible since this would be in the middle of the first file.

The basic issue is that the boot loader is being built with a linker script that locates the reset vector at the 0x08000000 but he reset of the code at 0x080c000 and so leaves a large gap between the two which makes the file large (this can be seen by opening the binary file in a hex editor and shows a large amount of 0x00 being inserted).

I believe the line in the linker script doing this is:

define symbol __ICFEDIT_region_CODE_start__ = 0x0800c000;

and is designed for use by programs that leave two flash sectors free for use by the parameter system. Since the boot loader doesn't use the parameter system this line is not appropriate and if you remove it it will presumably then generate loader code that is all in the first flash sector (and small).


The IAR out format is ELF format, which is not generated. You will therefore need to use a different loading technique than IAR's (which only allows loading files that it has created). ST Micro has a utility that is often used for this and, once the loader and the initial application are installed subsequent uploads can be performed by the application's loading method.

Regards

Mark

TeeYi:
Hi Mark,
    Thanks for your clarification.

    By using Segger J-Flash, I manage to combine the both file & program on the MCU. But it still not working.
    After that by using IAR, I try to debug on the uTaskerBoot which I found two problem on (uTaskerBootLoader.c):

1)   The firmware never run the " start_application(UTASKER_CODE_START) " when compile for STM32, so I add defined _SMT32  as
       as below for the compiler.


#elif defined _STM32 || defined _HW_AVR32 || defined _RX6XX || defined _KINETIS || defined _LM3SXXXX || defined _LPC17XX || (defined _M5223X && (defined _GNU || defined _COMPILE_IAR)) // {14}{17}{19}{20}{21}
    #if !defined _WINDOWS
    start_application(UTASKER_CODE_START);                               // jump to the application
    #endif
#endif


2) when the program run  [ if (fnCheckNewCode(&file_header))], it will cause HardFault exception
    static void irq_hard_fault(void)
   {
    }
   I attached the print screen (IAR) for your reference.

   When I change the routine as below,

static int fnCheckNewCode(UPLOAD_HEADER *file_header)
{
    return 0;
   
}
      After compile again & combine both file (uTaskserBM and uTaskerBoot), my board success boot up and running my program.
   
      Please advice how to solve the problem for fnCheckNewCode(UPLOAD_HEADER *file_header) routine.
     
      For your information, I am using SMT32F407ZET6 .
      Thanks & best regards.
   
       Tee
     
   

mark:
Hi

I am sorry that i didn't respond earlier:

1. I also found that the jump was not enabled for STM32 and the new dependency is correct.

2. I don't see the code causing the hard fault but I assume that it is due to the routine checking the flash content at an incorrect address/range (if you look at the call stack you can see the routine that resulted in the error - and also if you single step out of the hard fault handler (in disassembly mode) it will return to the instruction causing the error. You can see what address the instruction is using and verify that the range set up for the check is suitable for the part in question (like uFILE_START and UTASKER_APP_START).

Regards

Mark

TeeYi:
Hi Mark,
    Thanks for your reply.
    I already found the problem which cause the firmware halt (when call this function fnCheckNewCode(&file_header)). Basically it cause by stack overflow, and it can be solved by increase the stack size (in .lcf file)

define symbol __ICFEDIT_size_cstack__ = 0x400;
    Thanks.
    Tee

Navigation

[0] Message Index

[#] Next page

[*] Previous page