Author Topic: FRDM-KE06Z and uTasker KBOOT questions and observations  (Read 4214 times)

Offline nostar

  • Newbie
  • *
  • Posts: 3
    • View Profile
FRDM-KE06Z and uTasker KBOOT questions and observations
« on: May 12, 2018, 06:26:54 PM »
Hello forum,

I am running uTaskerSerialBoot in KBOOT mode on a FRDM-KE06Z and everything is working correctly.   I am able to load / reload the test bin on the website and my own KDS processor expert code after modifying the linker addresses to 0x8000.  I think that the uTasker implementation of KBOOT does not offer an 'app to boot' entry point like described in the NXP KBOOT manual, so I was thinking about trying to implement one of my own.  Looking thru the code, I thought one option could be to create a new entry point function that bypasses fnUserHWInit() altogether (so fnJumpToValidApplication() never gets called) or maybe add some code in the application that sets some reserved area in RAM to a sequence of bytes (lets say 0x12345678), then check for that sequence in addition to the FORCE_BOOT() switch in fnUserHWInit():

Code: [Select]
if ((FORCE_BOOT() == 0) && (*ram_from_app != 0x12345678)) {
        _DELETE_BOOT_MAILBOX();                                          // {13}
        fnJumpToValidApplication(0);                                     // {25} check for forced boot mode or no application code
    }

My question there is how to create an area in RAM that is guaranteed to be valid for both the app and the bootloader.


Meanwhile, this is a great project.  I found some issues on the FRDM-KE06Z page and some changes I made that might make sense for this board that I would like to share.

http://www.utasker.com/kinetis/FRDM-KE06Z.html

It says that J4-15 low with a reset disables the watchdog, but the code has SWITCH_1 set to KE_PORTG_BIT4, which is J5-2.  KE_PORTG_BIT3 is the correct port for J4-15.  All 3 of these pins require that headers be soldered to the board and jumper wires used though, so I made the change below, which sets the FORCE_BOOT and WATCHDOG_DISABLE to the 2 on-board switches of the FRDM-KE06Z board:
Code: [Select]
#define SWITCH_1               (KE_PORTH_BIT4)
#define SWITCH_2               (KE_PORTH_BIT3)

« Last Edit: May 12, 2018, 06:28:38 PM by nostar »

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: FRDM-KE06Z and uTasker KBOOT questions and observations
« Reply #1 on: May 12, 2018, 11:24:11 PM »
Hi

This technique is foreseen using the "BOOT_MAIL_BOX"
Example:
#define FORCE_BOOT()           ((_READ_PORT_MASK(A, SWITCH_1) != 0) || (((SIM_SRSID & SIM_SRSID_SW) != 0) && (*(BOOT_MAIL_BOX) == RESET_TO_SERIAL_LOADER)))

Either the standard GPIO input can be used to reset to the loader or else the application can write the value RESET_TO_SERIAL_LOADER (0x89ac) to the BOOT_MAIL_BOX location (#define BOOT_MAIL_BOX           (unsigned short *)(RAM_START_ADDRESS + (SIZE_OF_RAM - 2))) and command a reset (using fnResetBoard() - this is the Cortex System Reset command). The second is only recognised when it was a reset command (SIM_SRSID is the "System reset and Status ID" register in the KE06 and SIM_SRSID_SW is set after a reset that was commanded as such). Note that the mailbox value is always cleared so that it can only be detected once (the line _DELETE_BOOT_MAILBOX();).

You will note that the application (and loader) don't set the stack pointer to the top of SRAM but instead leave some space for such variables that are preserved across resets. This space is never used for anything else.

See kinetis.c:
const _RESET_VECTOR __vector_table
    (void *)(RAM_START_ADDRESS + (SIZE_OF_RAM - NON_INITIALISED_RAM_SIZE)), // stack pointer to top of RAM
    (void (*)(void))START_CODE,                                          // start address
}


The locations that are presently reserved are:
    #define BOOT_MAIL_BOX           (unsigned short *)(RAM_START_ADDRESS + (SIZE_OF_RAM - 2))
    #define RANDOM_SEED_LOCATION    (unsigned short *)(RAM_START_ADDRESS + (SIZE_OF_RAM - 4)) location of a short word which is never initialised and so has a random power on value
    #define RTC_SECONDS_LOCATION    (unsigned long *)(RAM_START_ADDRESS + (SIZE_OF_RAM - 8))
    #define RTC_ALARM_LOCATION      (unsigned long *)(RAM_START_ADDRESS + (SIZE_OF_RAM - 12))
    #define RTC_VALID_LOCATION      (unsigned short *)(RAM_START_ADDRESS + (SIZE_OF_RAM - 14))
    #define RTC_PRESCALER_LOCATION  (unsigned short *)(RAM_START_ADDRESS + (SIZE_OF_RAM - 16))

and users can extend this with custom ones by adding a define called PERSISTENT_RAM_SIZE with the additional space required.

If you try this technique (make the change in the FORCE_BOOT() define and use *(BOOT_MAIL_BOX) and fnResetBoard() in the application) you should find that it solves all of the issues.


You are right about the mistake with the input that disables the watchdog! On the diagram this connector pin has the name PTG3_GPIO4. I think that the GPIO4 that they added to the name caused confusion.... I changed the pin on the FRDM-KE06Z page to J5-2 so that it matches with the reference SW there.
I don't know why the connectors were used for these functions and not the board's switches (the switches are usually used). Your changes are however good if these are preferred!

Regards

Mark







Offline nostar

  • Newbie
  • *
  • Posts: 3
    • View Profile
Re: FRDM-KE06Z and uTasker KBOOT questions and observations
« Reply #2 on: May 13, 2018, 08:49:13 PM »
Great, that works perfectly!

RESET_TO_SERIAL_LOADER was not defined anywhere in the uTasker source, so I defined it myself and used my own value.

I needed to change (_READ_PORT_MASK(A, SWITCH_1) != 0) to (_READ_PORT_MASK(B, SWITCH_2) == 0) in the new FORCE_BOOT() define.

-Doug

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: FRDM-KE06Z and uTasker KBOOT questions and observations
« Reply #3 on: May 13, 2018, 10:43:48 PM »
Doug

It may be that the open source version doesn't have the command defined, so adding any value that is shared between application and loader is correct.

Regards

Mark

« Last Edit: May 14, 2018, 12:50:13 AM by mark »

Offline nostar

  • Newbie
  • *
  • Posts: 3
    • View Profile
Re: FRDM-KE06Z and uTasker KBOOT questions and observations
« Reply #4 on: May 30, 2018, 07:18:12 PM »
Hello again,

Ive been tinkering with the bootloader code, and I can't get pins on Port C to work to force a reset:

Code: [Select]
#define SWITCH_2               (KE_PORTC_BIT6)

or

Code: [Select]
#define SWITCH_2               (KE_PORTC_BIT7)

Is Port C not initialized or not configured as inputs in the bootloader?

EDIT: Nevermind, Port C is on GPIOA, the others are on GPIOB and I didnt make the change in _READ_PORT_MASK()
« Last Edit: May 30, 2018, 08:10:07 PM by nostar »

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: FRDM-KE06Z and uTasker KBOOT questions and observations
« Reply #5 on: May 30, 2018, 10:55:47 PM »
Hi Doug

The port naming is unfortunately a pain for the KE/KEA series.
They have 32 bit ports but are named as 4 x 8 bit ports A,B,C and D.
They are, apart from the naming convention, basically the same as other Kinetis parts and the only explanation that I have for this is that Freescale - who targeted the KE and KEA devices at 8 bit users - wanted to make the 8 bit users feel more at home when changing.
The result is however unnecessary portability/compatibility difficulties and the method chosen was to use KE_PORTC_BIT7 rather than PORTC_BIT7 so that it is clear that the KE port is being addressed. KE_PORTC_BIT7 is however actually PORTA_BIT23 when using its 32 bit registers.
The resulting confusion is that whereas the normal
_READ_PORT_MASK(A, PORTA_BIT23)
makes perfect sense
_READ_PORT_MASK(A, KE_PORTC_BIT7)
doesn't and one needs to remember that A is used for KE ports bits A,B,C and D....

I am wondering whether it would be possible to manipulate the macro and the registers slightly to be able to do something like
_READ_PORT_MASK(KE_C, KE_PORTC_BIT7)
which would be less error prone?
100% portability is still not possible but it may be closer.

Since you have solved this now you probably wont get caught out again though.

Regards

Mark