AnsweredAssumed Answered

Something wrong with AN2295 bootloader on FRDM-KL25Z for its reset behaviour

Question asked by Kai Liu on Aug 13, 2013
Latest reply on Oct 9, 2013 by Kai Liu

AN2295 doesn't work well on FRDM-KL25Z. Additionally, it is hardly to be debugged on FRDM. And here is my evaluating report.

 

A: H/W doesn't work with AN2295 firmware in OpenSDA. (solved)

 

I enable "Kinetis L Debug" and changed following project options.

    General Options\Target\Device: Freescale MKL25Z128xxx4

    Debugger\Setup\Driver: PE micro, Run to: __main

    Download\Verify download checked + Use flash loader + Override "$TOOLKIT_DIR$\config\flashloader\Freescale\FlashKLxx128K.board"

    PEmicro\Setup\OpenSDA-USA

 

The previous options are configured in simulator and run to "main", which will be complaint by debugger for "can not run to main".

 

It takes me quite a long time before I realize that I am working in a simulator mode.

 

B: Strange reset behavior. The code only runs to __main until a system reset from an invalid address. (partly solved)

 

When I click reset in IAR debugger, the code will stop at __main. Look good? No!

If I enable bkp on UART_Initialization(), the reset will stop at this function, instead of __main().

 

I traced its every step in disassembly, I found it runs in following ways.

 

    reset -->    // 0x0000

    UART_Initialization();  // @0x0040

    ......

    TIMER_DEINIT(BOOT_CALIBRATION_TIMER_BASE);  // by timeout

    ......

    JumpToUserApplication();    // @0x041C: jumps to an invalid memory

    --> __main  // 0x0540

 

That means when I pressed reset, the software goes to UART first, then it goes to invalid memory after timeout, then it stops on __main due to system reset. What an amazing loop!

 

Additionally, the map file is different from disassembly window, which has a byte shift.

 

    *.map file:

    UART_Initialization     0x00000041

    JumpToUserApplication       0x0000041d

    __main      0x00000541

 

I know some startup functions will be called before main(), that is normal. But this situation is strange, since UART function is not part of startup. That is definately a bug. I checked its vector table, which contains 16 vectors. Although KL25Z have 48 vectors, the first 16 vectors are core vectors. In bootloader mode, UART is not interrupt driven, it is enough. I will add more periperal vecotrs anyway, as additional test.

 

For some reason, the reset vector has not directed to __main. Alternatively, the reset in debugger has not performed a real reset. It runs for a while, then stops on __main.

 

Attached disassembly log.

 

    UART_Initialization():

    0x05F0: 0xF7FF-0xFD26   BL      UART_Initialization

    @0x0040:    UART_Initialization

 

    JumpToUserApplication(*((unsigned long*)RELOCATED_VECTORS), *((unsigned long*)(RELOCATED_VECTORS+4)));

    0x07CC: 0xF7FF-0xFE26   BL      JumpToUserApplication

    @0x041C:    JumpToUserApplication

 

    __asm("mov pc, r1"); // PC = 0x00000424, R1 = 0xD100286F

 

    -> __main() @0x0540

 

Update

 

I have changed its linker file (AN2295_LinkerFile.icf), by changing

define symbol IntVectTable_end__                = 0x000003FF; // original value is 0x0000003F

 

It doesn't help.

 

Up to now, I have no idea to force debugger to stop at __main first, instead of UART_initialization.

 

Temp solution

 

By accident, I found if run to parameter is blank, the debugger will stop at __main/main without running to UART function. That is wired. However now it works.

 

C: Why system jumps to user application even it is invalid? (partly solved)

    I know it may lead to reset to run bootloader again, but why using such a ugly approach? Maybe WDT is good enough? By enable it and wait for reset? Or software reset?

 

Please correct me if I have anyhting wrong. Attachment is my revised (adding GPIO to toggle LED as indicator).

 

D: Why bootloader use __main to replace main()? (solved)

Is there any particular reason behind this replacement?

 

I changed __main to main, by changing three places:

IDE options, stack

Project options, program entry

bootloader.c, all __main

 

However, it doesn't matter if program entry is main or __main.

 

Please help out of this issue since it confuses me a lot.

 

Currently I enforced it into bootloader mode, with LED indicator. I know it MAY work in such situation. I am still working on it. But its reset behavior always a nightmare for me.

 

Update and Temp solution (2013-08-15)

A: H/W doesn't work with AN2295 firmware in OpenSDA. (solved)

     Change debugger from Simulator to PEmicro/OpenSDA and other project options in "Kenitis L Debug" configuration.

B: Strange reset behavior. The code only runs to __main until a system reset from an invalid address. (partly solved)

C: Why system jumps to user application even it is invalid? (partly solved)

     Keep run to parameter as blank, nor "main" neither "_main". That is a common solution for B & C.

D: Why bootloader use __main to replace main()? (solved)

     It is easy, you can change options from __main to main.

E: Baudrate error (partly solved)

     Change default baudrate to 57600, it works on my PC now.

F: Without demo application (I'm working on it)

     FSL should at least offer a demo project for AN2295, such as FRDM-KL25Z-DEMO-w/ AN2295 bootloader project. I am working on it now. It may have more issues.


The source code is almost same, so I don't upload it again.


Well, it seems FSL should update AN2295 for KL25Z. It could save use a lot of time, time to market. And FSL' time to collect orders from us. isn't it?

 

Message was edited by: Kai Liu

Original Attachment has been moved to: Kinetis_rev2_strange_reset.zip

Outcomes