Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - kevinR

Pages: [1]
1
NXPTM M522XX, KINETIS and i.MX RT / Re: MK22FN1M0VLH12 port using Blaze_K22
« 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!

2
NXPTM M522XX, KINETIS and i.MX RT / Re: MK22FN1M0VLH12 port using Blaze_K22
« 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.


3
NXPTM M522XX, KINETIS and i.MX RT / Re: MK22FN1M0VLH12 port using Blaze_K22
« 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...

4
NXPTM M522XX, KINETIS and i.MX RT / Re: MK22FN1M0VLH12 port using Blaze_K22
« 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.

5
NXPTM M522XX, KINETIS and i.MX RT / Re: MK22FN1M0VLH12 port using Blaze_K22
« 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.

6
NXPTM M522XX, KINETIS and i.MX RT / Re: MK22FN1M0VLH12 port using Blaze_K22
« 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!







7
NXPTM M522XX, KINETIS and i.MX RT / Re: MK22FN1M0VLH12 port using Blaze_K22
« on: August 15, 2017, 04:16:05 AM »
I finally had some time on this again.  I think I see how the tasks work, and I can set breakpoints in fnTaskWatchdog() and see it is serviced.  I reconfigured the watchdog LED to my hardware and it now blinks.  I trust that more than the debugger :).

fnTaskUSB() is still never serviced which I guess means the firmware is not enumerating for some reason.  I know the USB hardware works with my user firmware, so I wonder what isn't getting setup correctly.

8
NXPTM M522XX, KINETIS and i.MX RT / Re: MK22FN1M0VLH12 port using Blaze_K22
« on: August 09, 2017, 09:24:16 PM »
I am still trying to digest how uTasker works, but I think fnTaskUSB() from usb_device_loader.c needs to be called somewhere, but when I set a breakpoint in this function it is never called.  It looks like uTaskerSchedule() is called in a while loop in kinetis.c, but it isn't doing anything that I can see.

9
NXPTM M522XX, KINETIS and i.MX RT / Re: MK22FN1M0VLH12 port using Blaze_K22
« on: August 09, 2017, 08:37:36 PM »
Update: I'm able to debug the serial bootloader now.  I tried "K_1M_128.ld" instead of "K_1M_128_Blaze.ld" for the linker and now it works.  I'm trying to find my away around the code now, but at least I can step through and see where it goes.  I don't see any MSD devices.

As an aside, I have custom hardware and there is no standard NXP development boards for this micro that I know of.  When I flash my normal FW onto the board it responds fine as a USB CDC device, so I think the HW checks out.

10
NXPTM M522XX, KINETIS and i.MX RT / Re: MK22FN1M0VLH12 port using Blaze_K22
« on: August 03, 2017, 10:24:24 PM »
I'm still stuck. I've tried directly flashing the srec, hex and bin files from "uTasker-Kinetis\uTaskerSerialLoader_FLASH", but maybe I'm not doing something right.  Attached are some screenshots of my debug configuration.  Does anything look wrong? I created a scratch workspace, but that didn't help.  It also says it can't find the source in the debugger perspective.

11
NXPTM M522XX, KINETIS and i.MX RT / Re: MK22FN1M0VLH12 port using Blaze_K22
« on: August 03, 2017, 04:25:33 PM »
What about the clocking? I have a 16 MHz crystal and I specify 10 pF load via the Kinetis registry.  Does the Blaze_K22 bootloader need to set this up or can it run independently?  A while back when I setup this micro I thought it required an external clock for USB.

12
NXPTM M522XX, KINETIS and i.MX RT / Re: MK22FN1M0VLH12 port using Blaze_K22
« on: August 03, 2017, 03:00:42 PM »
Thank you for the tips about how to enter the bootloader via software.  At the moment, I'm still battling trying to debug the bootloader.  Attached is a screenshot showing what happens when I run the debugger.  Can you make sense of what I'm seeing?

13
NXPTM M522XX, KINETIS and i.MX RT / Re: MK22FN1M0VLH12 port using Blaze_K22
« on: August 02, 2017, 06:33:59 PM »
Mark, thank you for the fast reply.  Yes, I just saw those defines for the LCD and it now compiles.

I setup my P&E debugger to debug the project, but nothing appears to happen and no USB MSD device shows up. It looks like it is trying to launch the user app which is currently blank.  By default the debugger sets a breakpoint at main, but I didn't find this anywhere.  I'm new to uTasker, so I don't know where the entry point is for the project to debug it.

With my custom hardware, I don't have any dedicated boot pin so maybe this is my problem with the default configuration.  My plan was to alter the decision somewhere to enter the bootloader based upon reset source (Kinetis registers RCM_SRS0 and RCM_SRS1).  If the reset source is the reset pin (my hack for a bootloader pin) or a SW reset (my user app launches the bootloader by forcing a reset) then the bootloader should be entered.  Where is the decision currently made?

Thanks for any help!

14
NXPTM M522XX, KINETIS and i.MX RT / MK22FN1M0VLH12 port using Blaze_K22
« on: August 02, 2017, 04:49:48 PM »
I'm interested in the serial bootloader ported to the MK22FN1M0VLH12 (or very similar MK22FN1M0AVLH12).  The Blaze_K22 supported with uTasker uses the same micro, so under the config.h I un-commented #define BLAZE_K22.  I followed the quick start video for KDS, chose the "K_1M_128_Blaze.ld" linker.  When I compile, I receive the following error:

fatal error: widgets.h: No such file or directory   serial_loader.c   /uTaskerV1.4/Applications/uTaskerSerialBoot   line 59   C/C++ Problem

I'm not interested in supporting the Blaze and it's display (which I assume the widgets.h is for??).  Is there a way to proceed in building the serial bootloader for the MK22FN1M0VLH12 or should I start from a different process.

Thanks,
Kevin

Pages: [1]