MK22FN1M0VLH12 port using Blaze_K22

[kevinR]

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

[mark]

Hi Kevin

If you execute \Applications\uTaskerSerialBoot\widgets.bat (double click on it) it will generate the missing "widgets.h" file from the bit maps in \Applications\uTaskerSerialBoot\Images. (Build also needs _NO_CHECK_QUEUE_INPUT commented out in config.h)

However, if you don't have the Blaze TFT connected it doesn't make any sense in using the graphics interface in the serial loader. In order to remove this simply comment out
#define SUPPORT_GLCD
and
#define SUPPORT_TOUCH_SCREEN
in the Blaze section of config.h
and then it will build without any TFT interface.

Out of interest, this is how the BLAZE Serial loader looks when running (shown in the simulator):



Regards

Mark

[kevinR]

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!

[mark]

Kevin

Make sure that USB_INTERFACE is enabled if you want USB loading (eg. USB_MSD_DEVICE_LOADER type).

The entry point tends to be (exceptions may apply for certain IDEs - such as IAR which enters at static void disable_watchdog(void))


// Main entry for the target code
//
extern int main(void)
{

This will be hit every time, even if the loader jumps straight to the application.
Take a look at https://www.youtube.com/watch?v=bilc_4Cr7eo&index=13&list=PLWKlVb_MqDQFZAulrUywU30v869JBYi9Q which shows the serial loader being used with KDS (towards the end it shows the debugger connecting).

The blaze project forces the boot loader and waits a few seconds to see whether the touch screen is tapped, else it jumps to the application.
Without the touch screen part it will always boot into the mode and stay there as it is...

    #define FORCE_BOOT()            1                                    // always start the boot loader

You can see how other HW uses this to decide whether to jump or not (usually sampling a port state).

There is a small mail-box defined at the top of stack that can be used by an application to tell the boot loader to not jump.
Eg.
#define FORCE_BOOT() (((RCM_SRS1 & RCM_SRS1_SW) != 0) && (*BOOT_MAIL_BOX == 0x1234))

The application sets the pattern and command a software reset and then it will go to the loader mode.
BOOT_MAIL_BOX is the top 2 bytes of SRAM so the application should not use these if possible. There are others entries in the area used by uTasker applications but this may be the only one of interest in this case.

Regards

Mark

[kevinR]

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?

[kevinR]

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.

[mark]

Kevin

The Blaze uses this setup:

#elif defined BLAZE_K22
    #define OSC_LOW_GAIN_MODE                                            // oscillator without feedback resistor or load capacitors so use low gain mode
    #define CRYSTAL_FREQUENCY    16000000                                // 16 MHz crystal
    #define _EXTERNAL_CLOCK      CRYSTAL_FREQUENCY
    #define CLOCK_DIV            4                                       // input must be divided to 2MHz..4MHz range (/1 to /24 for 120MHz parts)
    #define CLOCK_MUL            30                                      // the PLL multiplication factor to achieve operating frequency of 120MHz (x24 to x55 possible)
    #define FLEX_CLOCK_DIVIDE    3                                       // 120/3 to give 40MHz
    #define FLASH_CLOCK_DIVIDE   5                                       // 120/5 to give 24MHz
    #define USB_CLOCK_GENERATED_INTERNALLY                               // use USB clock from internal source rather than external pin - 120MHz is suitable

The USB clock is derived from the 120MHz PLL and doesn't need an external one.
One can choose between OSC_LOW_GAIN_MODE enabled or not. When enabled the circuit have no caps or loading. If there is a feedback resistor n cap loading this usually needs to be disabled so that high gain mode is used.
If one doesn't work use the other (if it doesn't match the 16MHz crystal may not start).

The controllable loading is not used but the application can adjust these or change setting if it wants after the boot loader has started it.

Regards

Mark

[mark]

Kevin

After loading check the memory at 0x00000000 to verify that it matches the bin file (it starts with the SP and PC values).
From the screen shot it looks like no code is being loaded(?)

Beware also that it is never possible to step the initial code that enables or disables the watchdog so this has to be run over and not stepped though (due to HW watchdog behavior).

Regards

Mark

[kevinR]

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.

[mark]

Kevin

I checked all of the screen shots and don't see anything that is not correct. Just clicking the debug button should connect, program and it should then stop at the entry address.

Although I don't think that it would explain debugging issues check that the compiler target is set to Cortex-M4 (optionally with HW FPU) and that the linker script file chosen matches the device.
Do you have a standard reference board for cross-checking too, in case it is HW related?

If you would like to send a contact request to my Skype address we could have a quick look together using remote desktop sine I don't have any more suggestions at the moment to explain why the debugger has difficulties.

Regards

Mark

[kevinR]

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.

[kevinR]

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.

[mark]

Kevin

K_1M_128.ld is correct. The Blaze linker script version is linked to an offset (0x10000) so that it can be loaded using the Blaze's internal loader and so can't run when stand-alone.

This is how the system works (when set up for USB-MSD).
1. After disabling (or configuring the watchdog and the clock settings) it calls fnUserHWInit() in serial_loader. Here it checks whether there is application code to jump to or whether the user is forcing the loader (eg. by holding a switch at reset). Make sure that the flash is erased when starting so that it doesn't immediately jump to something (that can't run) or force the loader mode [see FORCE_BOOT() for decision]
2. Assuming it stays in the loader it calls
        fnInitialiseHeap(ctOurHeap, fnGetHeapStart());                   // create heap
   uTaskerStart((UTASKTABLEINIT *)ctTaskTable, ctNodes, PHYSICAL_QUEUES); // start the operating system
which will allocate HEAP memory and configure the tasks that will be run, plus start the TICK timer.
3. Now it will start a forever loop calling
uTaskerSchedule()
which will schedule the tasks "when they need to run".
4. ptTaskTable->ptrTaskEntry(ptTaskTable);                      // call the task
is the task call. If you put a break point on this you can see every task call.
5. Generally the tasks will be called like this:
fnTaskWatchdog() - toggles LED and retriggers the watchdog (if enabled)
fnTaskUSB() - initialises the USB device interface [indeed in usb_device_loader.c]
fnTaskWatchdog() (after 100ms)
fnApplication() - initialised UART (if enabled)
fnTaskWatchdog() (after 100ms)
fnTaskWatchdog() (after 100ms)
fnTaskWatchdog() (after 100ms)
etc.

5. The USB task will be called again only after the USB device driver has completed enumeration [interrupt driven] (when connected to a USB host)

If you check this sequence you may identify where a deviation is in your case.

Good luck

Regards

Mark

[kevinR]

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.

[mark]

Kevin

The USB task is called once to initialise the USB interface.
It is called a second time only after enumeration.

I have just checked again how the Blaze configuration operates and see the following, which is a little different to normal. It only actually enables the USB interface when the user taps on the display!

This is controlled in TaskConfig.h as follows:

        #if defined BLAZE_K22
    { "usb",       fnTaskUSB,      SMALL_QUEUE, (DELAY_LIMIT)(NO_DELAY_RESERVE_MONO), 0, UTASKER_STOP }, // USB (application) task is only started if commanded
        #else
    { "usb",       fnTaskUSB,      SMALL_QUEUE, (DELAY_LIMIT)(NO_DELAY_RESERVE_MONO), 0, UTASKER_ACTIVATE}, // USB (application) task
        #endif

Notice that the USB task is not started (it will be later started from the code that detects the user taping on the display). Therefore, since you don't have a display, you will need to change this so that the task is indeed started

For example, change the define decision to
#if defined BLAZE_K22 && defined SUPPORT_TOUCH_SCREEN
which will then cause the USB task to be started immediately if the touch display is not enabled.

This will very probably solve your problem!

Regards

Mark