topic Re: Something wrong with AN2295 bootloader on FRDM-KL25Z for its reset behaviour in Kinetis Microcontrollers

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

kai_liu — Tue, 13 Aug 2013 13:23:59 GMT

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

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

kai_liu — Wed, 14 Aug 2013 13:32:27 GMT

For Question B + C, the solution is disable project options' run to "main" or "__main". The debugger will reset to __main. Amazing debugger! If you want it, release it first.

Now, the new situation is wrong traffic in "ident" command.

In KL25Z, the ident response should be:

(Version), 0x88

(SDID-H), 0x14

(SDID-L), 0x86

(bootloaderIdent)

00 00 00 01 00 00 10 00 00 00 ff ff 00 00 10 00 00 00 00 00 00 00 04 00 00 00 00 80 4b 4c 32 00 00

And these byte arrays are verified in memory window. And I double verified it in uart_putchar(). However the real receiver on PC gets following traffic:

Traffic:

00 00 00 00 00 00 00 00 00 FC FC FC

88 14 86

80 80 80 01 80 80 10 80 80 80 FF FF 80 80 10 80 80 80 80 80 80 80 04 80 80 80 80 80 4B 4C 32 80 80

Then I enforeced to send bootloaderIdent in constant byte arrays, instead of structure def. But I got same result. It seems that UART_putchar are trimmed in a wrong timing?

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

BlackNight — Wed, 14 Aug 2013 15:12:21 GMT

There is a bug in the KL25Z silicon around UART baud, not sure if this is what you are seeing.

The problem depends on the clock path, see

Be Aware of the Baud Problem | MCU on Eclipse

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

kai_liu — Thu, 15 Aug 2013 02:31:50 GMT

Well, that is an useful information. Thanks!

Currently I slow-down its baudrate, so I got it working on 57600bps. Amazing.

I have updated and summary my discussion thread. It seems most of things are correct, unless we use in wrong way with wrong options.

Since FSL doesn't offer off-the-shelf demo for A2295, I am working on one with modified linker icf file.

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

kai_liu — Tue, 20 Aug 2013 23:52:45 GMT

I have shared my experiences on porting AN2295 to FRDM-KL25Z at FSL community:https://community.freescale.com/docs/DOC-95429

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

lander — Fri, 04 Oct 2013 20:39:23 GMT

Is letter A for CW (I'm on CW 10.4)? Or for IAR? I'm asking because the GUI (win_hc08sprg.exe) won't recognize my bootloader. I am trying to figure out these two: Download\Verify download checked + Use flash loader + Override "$TOOLKIT_DIR$\config\flashloader\Freescale\FlashKLxx128K.board" && PEmicro\Setup\OpenSDA-USA.

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

kai_liu — Tue, 08 Oct 2013 08:22:52 GMT

It should be AN2295, instead of A2295. Sorry for misleading you.

In my experience, the code is working well, but IAR should be configured correctly to be debugged first. You can try https://community.freescale.com/docs/DOC-95429 for detail.

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

lander — Wed, 09 Oct 2013 12:26:07 GMT

No no, you did not mislead me, no worries about that.

My problem is that I am not using IAR, I am using Code Warrior 10.4. I have my project running great but win_hc08sprg.exe will not recognize my bootloader. Is it more difficult to work with CW and an2295? So, I guess what I should have asked in my last post was... for letter A on this thread (A: H/W doesn't work with AN2295 firmware in OpenSDA. (solved)), is that directions for IAR or CW?

Thank you and sorry for any confusion.

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

kai_liu — Wed, 09 Oct 2013 23:30:02 GMT

I have not tested it on CW, since I am using open source gcc-arm + eclipse to replace it. As my experience, the win-hcsprg.exe is out of maintenance. So either check it in VC++, or develop your own with "glue" language. I know it is painful.