Using KBOOT v2 on KDS in Debug Mode

[#1]

The Kinetis Bootloader(KBOOT) v2 is now available on www.nxp.com/kboot webpage, it supports building bootloader image on KDS v3.2  IDE. About how to use the KBOOT to load a user's application on kinetis MCU please refer to the DOC”Kinetis Bootloader Demo Application User’s Guide”(It is under the KBOOT install package: NXP_Kinetis_Bootloader_2_0_0\doc).

When using KDS build the bootloader image, there is one point need to be paid attention: the image size in debug mode build is over 0xa000(the 0xa000 is user's application start address). That is to say , if we download the debug build image to mcu, can’t use it . So this doc povides the correct way to use the KBOOT on KDS, the problem shows in FRDM-K64 and FRDM-K22 boards, on other chips , if they also have the out of range problem, the correct method is the same .

How to correctly use the KBOOT v2 on KDS ? Please check this DOC on attachment !

[kennethtait]

Alice,

I'm trying to use the debug output messages in the kboot and don't quite understand how this works.

They all direct to vprintf() call, so where if anywhere do they appear in the debugger? I would have expected the console, but nothing output here?

Is ther somethin gelse that needs to be configured?

thanks

Ken

[Alice_Yang]

Hello Kenneth,

The kboot not print to the console , it use the GUI to show message and update the application.

And you can tell me which board do you used, and tell me which step crashed when you use it .

After you describe it detail , then i can help you .

BR

Alice

[kennethtait]

Alice,

I'm using a custom board that runs fine with the app we wrote for it, so

no hardware issues. It is based on MK22FN1m0 part.

when you say the KBOOT uses the GUI..what exactly do you mean? Normally

in most all IDEs when debugging, a printf() would go to the IDE console.

I don't see that here, so where does it go...Using vprintf is non

standard and in IMHO opinion bad practice for a bootloader. Everything

should use fixed buffer sizes only, no mallocs or dynamic lists.

What I did was take the MK22F515 platform and modified it as per the

reference manual. It compiles, links loads ok but fails at various points.

I patched the vectors for the additional UARTS

1. I am using UART4 in RS485 half duplex mode, so I had to add

support for the driver enable for this. I see that only UARTS 0,1 seem

to be tested had to patch a few things to get this to compile. I added

support for turning around the RS485 driver in the code.

2. I added support for an attached display board to see what's going

on. It also has the button we will use to enter the bootloader.

3. I want the baud rate to be fixed, no auto-baud, but there seems to

be no way to defeat this and this is giving me back a bad baud rate to

start.

If I comment out the flash_init() in bl_main. It comes up, runs my

display fine. Sets the driver bits correctly.

Using the flash load utility to ping it, I see the ping getting to the

receive pin, but it does not recognize it, probably due to the wrong

baud rate.

More digging in the clock init shows me this is failing to, So I put a

return there and take the default clock which should be enough since the

PIT and display are already running at this point.

Clock is failing because it is trying to init the usb clock even though

I have this defeated as per the reference manual.

This routine that checks for 1st available peripheral is not correct. It

reads the flash, sees all fs so it assumes it should try all

peripherals. the fact that you have manually disabled certain

peripherals is totally ignored here from what I can see...

Other bugs that were fixed:

#if BL_TARGET_FLASH in code is not being compiled correctly even though

it IS defined on compiler command line and in pre-processor directives.

This is because...#if is NOT the same as #ifdef to the pre-processor. It

may work in the IAR compiler but I guarantee you it doesn't work in the

GCC compiler. Fixed this and correct code gets compiled.

#define TERMINAL_NUM is totally useless, does nothing I can see?

The number of UARTS in the PLATFORM specific parts files is wrong.

256/512/1m parts all have 6 uarts not 3. This caused #if defs fail here

too...

I added the appropriate interrupt vectors for all the uarts.

So my opinion is that a few specific platforms and configurations were

tested and all the possible ones it can handle were not.

There is an emphasis on the IAR IDE, no mention of the KDS environment

it is on, so I'll bet most of this was cut and pasted or tested on older

distributions.

The BCA area and how to set this up is not explained well when it comes

to actually PUTTING it into the part.

I edited the .s file so that my configs, particularly which peripherals

are attached is correct, however the compiler and linker seem to be

ignoring this and programming it still does not change the locations. So

I'm missing some knowledge here...

ReadConfig() reads back all 0xff, and when I try to inspect it with

memory browser it gives me back ???? SO what is this?? I can look at

other flash locations just fine.

My conclusion is that the KDS on Linux is missing something here or that

there are a few more tricks not covered in the documention to get this

to go. There was a mention of JVM not being the right version for this

eclipse. I checked the eclipse site, it says 1.7 which IS what I have

installed.

Just so you know, I have written over a dozen bootloaders for various

chips, so not a newbie here. I am a very experienced programmer but this

is my first crack with the freescale environment. I have previous

experience with eclipse.

At this point I'm burning lots of time going round in circles. I can't

map out a credible debug strategy because I can't trust the tools.

So what do you recommend?

Ken

[Alice_Yang]

Hello Kenneth,

Sorry i think you misunderstand this DOC , it only introduce the point to use KBOOT on KDS in debug mode,

not the detail process about how to use KBOOT, about how to use it , you can refer to the DOC

”Kinetis Bootloader Demo Application User’s Guide”(It is under the KBOOT install package: NXP_Kinetis_Bootloader_2_0_0\doc).

And about porting the KBOOT to other chips , you can refer to the DOC :"Kinetis Bootloader v2.0.0 Reference Manual.pdf"

BR

Alice

[kennethtait]

Alice,

I understand perfectly, I think you are not absorbing all that I have said.

I have both of these documents and have followed them. They are missing

TOO MUCH detail information, that is the problem.

Who wrote this bootloader? I want simple questions answered: where is

the debug output going? why don't I see it?

How do I debug the flash init not coming up correctly? the linker file

looks ok, so how do I know what it is unhappy with?

I don't need any more finger pointing, I need answers...

Ken

[Alice_Yang]

Hello Kenneth,

- About the flash init , you can debug step by step and check the related register to find the problem.

- About the UART driver and baud rate, you can refer to your request to change code .

-There is a bootloader for MK22FN512, it is simple and easy to porting , i think you can use it :

Kinetis Bootloader to Update Multiple Devices in a Network for Cortex-M4  

you can print the debug information to any UART terminal when you debug your code , for  this needn't

handshake protocol between PC and board, and it only for one chip ,so the code is simple .

BR

Alice

[kennethtait]

Thanks,

I will take a look at it.

Unfortunately this board doesn't have a spare uart to output the debug

info, that's why I wanted to only see it in the debugger.

Ken

[DavidS]

Hi Ken

Please have a look at Segger RTT implementation.

https://mcuoneclipse.com/2015/07/07/using-segger-real-time-terminal-rtt-with-eclipse/

Regards,

David

[kennethtait]

Thanks David I will do that! putting out some other fires this morning....

Ken