Author Topic: MK22FN1M0VLH12 port using Blaze_K22  (Read 13530 times)

Offline kevinR

  • Newbie
  • *
  • Posts: 14
    • View Profile
Re: MK22FN1M0VLH12 port using Blaze_K22
« Reply #15 on: August 15, 2017, 06:43:03 PM »
Fantastic! That did the trick.  Now I see the MSD device showing up.  Thanks for finding this.

Now I just need to modify my user app to start at 0x8080.  Is that correct?  I'm using Processor Expert, and I've found where to change the parameters for the generated linker.  I assume I just add 0x8080 to both the m_interrupts and m_text?  Here is what the generated linker put out:

Code: [Select]
MEMORY {
  m_interrupts (RX) : ORIGIN = 0x00008208, LENGTH = 0x00000188
  m_text      (RX) : ORIGIN = 0x00008490, LENGTH = 0x000F7B70
  m_data      (RW) : ORIGIN = 0x1FFF0000, LENGTH = 0x00010000
  m_data_20000000 (RW) : ORIGIN = 0x20000000, LENGTH = 0x00010000
  m_cfmprotrom  (RX) : ORIGIN = 0x00000400, LENGTH = 0x00000010
}

I also setup my project to output raw binary bin file.  At present I can copy the .bin file to the MSD and the file shows up, but it does not run after I power cycle the board.  The loader shows back up empty.

I saw your article (http://www.utasker.com/forum/index.php?topic=1869.0), and so I think I may be doing something wrong with the vector table address and 512 byte boundary.  Can I make the start at 0x8000 instead or does this cause problems.  Otherwise, I'm not following where I place the code to copy the vector table to SRAM.

By the way, for some reason I cannot get the bootloader to run on a cold power up.  I have to toggle the reset line before it comes up.  I have not done anything yet to the FORCE_BOOT().  It is always 1.  I suspect it has to do with not setting up the crystal loads, but I can test that.

Thank you again for you help!







Offline kevinR

  • Newbie
  • *
  • Posts: 14
    • View Profile
Re: MK22FN1M0VLH12 port using Blaze_K22
« Reply #16 on: August 15, 2017, 06:53:28 PM »
I think I made a mistake below.  I really wanted m_interrupts to start at 0x8080 and not 0x8208 as shown (I added 0x188 to 0x8080).  This still has the same behavior as before.

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: MK22FN1M0VLH12 port using Blaze_K22
« Reply #17 on: August 15, 2017, 08:04:53 PM »
Kevin

It is correct that m_interrupts needs too be at 0x8080.

m_cfmprotrom  (RX) : ORIGIN = 0x00000400, LENGTH = 0x00000010
is however wrong because it will be located before the reset vector.

This area is in fact of no use for an application working with a loader (the loader occupies this space and defines the Flash configuration parameters) and so you may be able to remove it from the code to get rid of it. If not, try to locate it between the reset vectors and the application. If you can avoid PE from overwriting the linker script you can also edit it manually - this should be what you need:

MEMORY {
  m_interrupts (RX) : ORIGIN = 0x00008080, LENGTH = 0x00000188
  m_cfmprotrom  (RX) : ORIGIN = 0x00008208, LENGTH = 0x00000010
  m_text      (RX) : ORIGIN = 0x00008218, LENGTH = 0x000F7DE8
  m_data      (RW) : ORIGIN = 0x1FFF0000, LENGTH = 0x00010000
  m_data_20000000 (RW) : ORIGIN = 0x20000000, LENGTH = 0x00010000
}


Usually a project will have an option to run vectors from Flash or in SRAM - if PE can't do this you can add a memcpy() to copy 0x188 bytes from 0x8080 to 0x1fff0000 and then write the Vector Table Offset Register: VECTOR_TABLE_OFFSET_REG = 0x1fff0000; [*(unsigned long *)0xe000ed08 = 0x1fff0000]

In order to keep vectors in Flash you can change the start address to 0x8200 (instead of 0x8080) and change
#define ROOT_FILE_ENTRIES         4                                  // when USB MSD loader this many directory entries are set to the start of FLASH - the application start is shifted by this amount x 32 bytes
to
#define ROOT_FILE_ENTRIES         16                                  // when USB MSD loader this many directory entries are set to the start of FLASH - the application start is shifted by this amount x 32 bytes
to adjust it in the serial loader.
This is necessary because the vector table must be 512 byte aligned for all the interrupts to be able to operate correctly.

Regards

Mark


Offline kevinR

  • Newbie
  • *
  • Posts: 14
    • View Profile
Re: MK22FN1M0VLH12 port using Blaze_K22
« Reply #18 on: August 15, 2017, 09:45:48 PM »
Alright, we're making great progress.  Thanks again for the guidance.  I chose to move the address out to 0x8200 to make things easier for me.  I manually deleted the m_cfmprotrom per your advice.  I can now load my .bin file to the MSD, and with FORCE_BOOT() set to 0, it will automatically launch my app after copying!  I'll play with changing FORCE_BOOT() later.

I'm still working on the startup issue, however.  My thought is it is a problem with the crystal configuration.  I'm trying to understand how the clock is configured in kinetis_K_CLOCK.h.  I'm wondering if I need to add the following somewhere to add the 10 pF of loading (2pF+8pF).

Code: [Select]
OSC_CR = (OSC_CR_ERCLKEN_MASK | OSC_CR_SC2P_MASK | OSC_CR_SC8P_MASK);
On Power-On-Reset, I'm not seeing anything on the clock lines with a scope.  When I cycle the reset pin, it does something to jar it and it oscillates at the 16 MHz.

Offline kevinR

  • Newbie
  • *
  • Posts: 14
    • View Profile
Re: MK22FN1M0VLH12 port using Blaze_K22
« Reply #19 on: August 15, 2017, 10:04:31 PM »
I see my code just has a slightly different definition for the OSC_CR register.  You have OSC0_CR instead.  I added the following loading to this line: 

Code: [Select]
OSC0_CR = (OSC_CR_ERCLKEN | OSC_CR_EREFSTEN | OSC_CR_SC2P | OSC_CR_SC8P);
(By the way, I found a typo for OSC_CR_SC8P.  It was originally OSC_CR_SC18P)

This still didn't do anything.  What I'm curious about is why KDS shows this line as inactive code by #if defined FLL_FACTOR || defined RUN_FROM_EXTERNAL_CLOCK.  I tried right after this inactive code the same line, but it doesn't work.

Looking at my lab supply that is powering the board, it draws around 12 mA when normally running after resetting.  On power on reset, the current draw is only about 1 mA.  It seems like it is stuck somewhere simple...

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: MK22FN1M0VLH12 port using Blaze_K22
« Reply #20 on: August 16, 2017, 01:00:01 AM »
Kevin

There is a define
OSC_LOW_GAIN_MODE
which is used by the Blaze since its crystal circuit has no loading (neither caps nor feedback resistor)
Try removing this, especially if you have R/C components in the hardware.

With the wrong setting the crystal often won't start-up. Sometimes touching the crystal is enough to get it going and sometimes not (when wrong).

This setting controls whether MCG_C2_HGO is set in MCG_C2 or not.
The place that the code gets stuck if not right is at
    while ((MCG_S & MCG_S_OSCINIT) == 0) {                               // loop until the crystal source has been selected

Regards

Mark

Offline kevinR

  • Newbie
  • *
  • Posts: 14
    • View Profile
Re: MK22FN1M0VLH12 port using Blaze_K22
« Reply #21 on: August 16, 2017, 04:59:57 PM »
It was little painful, but I think I found the issue.  My code disables NMI CPU interrupts (I think by disabling MCM_ETBCC bits RSPT and CNTEN) and sets the NMI_DIS bit in the FOPT for PTA4.  I use this pin for GPIO with an RC pull-up to 3.3V.  So on power-up the cap keeps this pulled low through reset.  When I bypass the resistor and tie PTA4 to 3.3V, the micro always boots!

I also disable the EzPort by setting EZPORT_DIS bit (also in FOPT) as well which I think may be equally important in my case.  I'm starting to recall this issue some years back.  I guess I'm re-discovering it.

So, can you kindly show me where I would set the flash configuration fields in uTasker.


Offline kevinR

  • Newbie
  • *
  • Posts: 14
    • View Profile
Re: MK22FN1M0VLH12 port using Blaze_K22
« Reply #22 on: August 16, 2017, 05:25:11 PM »
I found it.  It was actually the EZPORT that needed to be disabled as you already had the NMI disabled.  It is effected by the same pin (PTA4).

I changed:
#define KINETIS_FLASH_CONFIGURATION_NONVOL_OPTION  (FTFL_FOPT_EZPORT_ENABLED | FTFL_FOPT_LPBOOT_NORMAL | FTFL_FOPT_NMI_DISABLED)
to
#define KINETIS_FLASH_CONFIGURATION_NONVOL_OPTION  (FTFL_FOPT_EZPORT_DISABLED | FTFL_FOPT_LPBOOT_NORMAL | FTFL_FOPT_NMI_DISABLED)

Now all is well for booting every time on power up!

Now I'll just cleanup the FORCE_BOOT() decision and I think I'm done.  Thanks for the help, Mark!