Trouble with AN2295 bootloader on Kinetis K20

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Trouble with AN2295 bootloader on Kinetis K20

Jump to solution
3,720 Views
RickBall
Contributor II

I'm trying to use the 'Developer's Serial Bootloader' (Version 12, dated 9/2012) with a Kinetis MK20DX128VLH5 MCU on a custom board.

I've managed to get it to communicate over the serial port, but it reports some warnings with the ID/protocol, and then fails to program the flash.

The application it's trying to flash has been modified as suggested in the AppNote, by moving the flash base from 0 to 0x1000 (first protection block past the bootloader).

Here are the messages (with problems highlighted):

------------------------------------------------------------------------------

hc08sprg - Developer's HC/S08/CFV1/V2/Kinetis Serial Bootloader

$Version: 10.0.12.0$

------------------------------------------------------------------------------

FC protocol versions supported:

        0x01 (HC08)

        0x03 (large HC08)

        0x02 (S08)

        0x06 (long S08)

        0x0A (large S08)

        0x04 (ColdFire)

        0x08 (Kinetis)

------------------------------------------------------------------------------

Parsed S-record lines: 702  Bytes total: 53024

Source address range: 0x1000-0xDF2F

Waiting for HC(S)08/ColdFire/Kinetis reset ACK (timeout: 8s)...received 0xfc (good).

WARNING! The protocol version [0x08] (Kinetis) does not match the one associated

with the device with following SDID [0x015].

Protocol version for given SDID should be [0x02] (S08).

Continuing with reported protocol version anyway.

Something is screwed up, please report!

Bootloader protocol version: 0x08 (Kinetis, read command supported,

Protocol secured: CRC-CCITT)

Bootloader version string: K20

System device ID: 0x015 [MC9S08RA16] rev. 1

Kinetis Package: 64-pin .

Number of memory blocks: 1

Memory block #1: 0x00001000-0x0000FFFF

Erase block size: 2048 bytes

Write block size: 128 bytes

Original vector table: 0x00000000-0x000003FF

New vector table: 0x00001000-0x000013FF

The S19 image also contains redirected vectors. The automatic redirection is skipped now.

Are you sure to program part? [y/N]: y

Memory is erased.

Memory programming block 0: W 0x00001000 0%

Can't program block 0 at address 0x00001000

Program memory failed.

Has the bootloader been tested with this K20 part? I checked the datasheet, and it looks like 0x0015 is the correct ID for the part, but maybe it also applies to the older MC9S08RA16 device?


Any suggestions for how to find/fix the problem?


Thanks,


Rick Ball

Labels (1)
0 Kudos
Reply
1 Solution
1,573 Views
jiunnyang
NXP Employee
NXP Employee

Hi,

Here is for your reference.

I have modified the source for K20DX128VLH5.

In order to use MCG, some crystal was necessary.

Have fun :smileyhappy:

View solution in original post

0 Kudos
Reply
7 Replies
1,573 Views
pataga
Contributor I

I now have reliable AN2295 serial uart bootloader programming of a K20 part ( MK20DX128VLF5 ) using the bootup FEI clock,  at 57600baud, i.e. no crystal required.

This is working fine with a USB serial comm  using an FTDI chip (FT232).

These are the things i noted / modified in the bootloader firmware ( I am using the master software AN2295 GUI without modifications)

1. max baudrate 57600

2. BOOT_BUS_CLOCK is not 25000000, but 32768*640 (20971520UL), which is the slow IR clock + FLL.

3. clock trimming removed

4. CRC code removed 

5. FLASH_WRITE_ACCESS set to FLASH_WRITE_ACCESS_LONG

6. FLASH_INIT_FLASH_CLOCK  reduced  SIM_CLKDIV1_OUTDIV4(2)

7. uart  rx fifo enabled with 16 bytes

8. SRS_ xx aliased to RCM_SRS0, not MC_SRSL (which is not found in MK20DX5.h)

9. pull up needs to be enabled on boot pin with PORT_PCR_PS_MASK

10. reading SIM_SDID register == 0x1014,  NOT 0x1114 as the datasheet specifies !!  If you mask off the top nibble (chip rev) and bottom nibble (package), the sdid returned is 0x010  not the 0x110 that the code in the AN2295SW master application  expects for a K20 part. Since others have noted the same issue, i'm guessing i don't have counterfeit parts :-)

11. I modified the timeout code before the bootloader jumps to application, to not use timer hardware, but simple delay loops.

Am sure not all these changes were required e.g. 11, but in the process of trying to get it to work from as simple a base as possible ... code is attached for reference.

0 Kudos
Reply
1,573 Views
harshpatel
Contributor IV

Thank you Hari Nair

  your code is very helpful for us and i have modified as per my requirement  But i found a problem while using this code...

PROBLEM IS..

first time while loading application (ex. app1.srec) with application offset 0x1000 using An2295 its working fine. now when i am trying to load new application(ex. app2.srec)  with 0x1000 offset on same bootloader code it will generate following error....

"Can't program block 0 at address 0x00001400"

linker file configuration is as follows for your reference:

MEMORY {

  m_interrupts (RX) : ORIGIN = 0x00001000, LENGTH = 0x000000F8

  m_text      (RX) : ORIGIN = 0x00001410, LENGTH = 0x0001FBF0

  m_data      (RW) : ORIGIN = 0x1FFFE000, LENGTH = 0x00002000

  m_data_20000000 (RW) : ORIGIN = 0x20000000, LENGTH = 0x00002000

  m_cfmprotrom  (RX) : ORIGIN = 0x00001400, LENGTH = 0x00000010

}

so please can you help me to solve this problem as soon as possible..???

waiting for you input...

Thank you

0 Kudos
Reply
1,573 Views
johnnymclean
Contributor II

Hi Hari

If you're out there, hoping you could provide more detail on what you mean by 7 above? (uart rx fifo enabled with 16 bytes)

I'm trying to get an2295 running on a FRDM_K64F dev kit. I've cut the trace so the k64 is isolated from the k20(OpenSDA interface) and can flash the chip directly from it's jtag port. I'm flashing my an2295 build successfully to the k64. I get output on uart0, but it's garbled, like I have the wrong baud rate. My build is setting baud rate to 115200. No matter what I've tried, I get garbled output. I've building with other baud rates defined, but no difference.

Thanks, Johnny

0 Kudos
Reply
1,573 Views
mjbcswitzerland
Specialist V

Hi Johnny

Hari would have enabled the Rx FIFO (by setting RXFE in UARTx_PFIFO).

However the Rx FIFO size is fixed at 8 for the K20 (and also your K64) so can't be set with other depths - this detail is therefore not exact.

If not enabled, the receiver will be in legacy mode with a single buffer depth of 1.

This is however not relevant for the transmitter operation and also generally not of great importance when not working with high speeds and appications where the input (interrupt) can't be serviced within 2 character periods.

Note that not all Kinetis UARTs have FIFOs so a generic solution would not rely on them being used.

Regards

Mark

Kinetis: µTasker Kinetis support

K64: µTasker Kinetis FRDM-K64F support / µTasker Kinetis TWR-K64F120M support

For the complete "out-of-the-box" Kinetis experience and faster time to market

0 Kudos
Reply
1,574 Views
jiunnyang
NXP Employee
NXP Employee

Hi,

Here is for your reference.

I have modified the source for K20DX128VLH5.

In order to use MCG, some crystal was necessary.

Have fun :smileyhappy:

0 Kudos
Reply
1,573 Views
pataga
Contributor I

Oops, just saw this thread, I was following and commenting in another thread  "AN2295-SW serial bootloader for MC9S08SH8CTG" because the OTP reported the same initial error message.

I am using a K20 part, MK20DX128VLF5.

I too get the device id misidentification by the GUI though it is correctly reported by the bootloader as 0x014. 

I finally resolved my issues with the AN2295 bootloader, no crystal was necessary and should not be required anyway. The issues and my fixes are reported on the above thread !

0 Kudos
Reply
1,573 Views
Hui_Ma
NXP TechSupport
NXP TechSupport

Hi,

There is a document about how to port AN2295 to Kinetis K21 50MHz product with below link:

https://community.freescale.com/docs/DOC-95039

Wish it helps.