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.


Topics - mark

Pages: 1 2 3 [4] 5 6 ... 19
46
Hi All

If any KDS users are finding that builds work OK for the selected target but the excluded files are not displayed correctly, please see this thread:
https://community.freescale.com/message/511276#511276
There is a setting that can be adjusted with allows it to work as expected!

Regards

Mark

Summary:
1. Open the main project properties and then expand C/C++ General, followed by Indexer
2. Enabled "Enable project specific settings"
3. Change the radio button from "Used a fixed build configuration" to "Use active build configuration"
Done.

47
NXPTM M522XX, KINETIS and i.MX RT / FRDM-K64F mbed loader version
« on: April 07, 2015, 08:25:10 PM »
Hi All

It seems like there are still some FRDM-K64F boards floating around with an old mbed loader installed which won't load software if the flash configiration area is not set to a certain pattern - see http://developer.mbed.org/questions/3323/Loader-crashing-when-flash-configuration/

In case you find yourself affected it can be resolved by installing the latest mdeb loader version.
How to do this is aso explained at http://developer.mbed.org/handbook/Firmware-FRDM-K64F and sumarised here (also the latest SW can be found at that link):


1. Disconnect the board
2. Hold the reset button down and connect the OpenSDA USB cable - the board now appears as BOOT_LOADER hard disk
3. Drag and drop the attached file to it [20140530_k20dx128_k64f_if_mbed.bin]
4. Disconnect and reconnect the USB cable (power cycle - without holding the RESET button down)
Now the new debugger is installed and will allow loading any code.


For anyone interested in how the Flash Configuration settings are defined in the project you can look in the app_hw_kinetis.h file in the corresponding project to find the original workaround to this (commented out and possibly deleted entirely at some point)

//#if defined FRDM_K64F                                                  // (removed since mbed bootloader has been corrected) since this board may be used with the MBED loader the flash configuration settings are left with all bits apart from security disable set at '1' - otherwise the MBED loader tends to crash
//  #define KINETIS_FLASH_CONFIGURATION_BACKDOOR_KEY       {0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff}
//  #define KINETIS_FLASH_CONFIGURATION_PROGRAM_PROTECTION {0xff, 0xff, 0xff, 0xff}
//  #define KINETIS_FLASH_CONFIGURATION_SECURITY           (0xfe)
//  #define KINETIS_FLASH_CONFIGURATION_NONVOL_OPTION      (0xff)
//#endif



    #define KINETIS_FLASH_CONFIGURATION_BACKDOOR_KEY       {BACKDOOR_KEY_0, BACKDOOR_KEY_1, BACKDOOR_KEY_2, BACKDOOR_KEY_3, BACKDOOR_KEY_4, BACKDOOR_KEY_5, BACKDOOR_KEY_6, BACKDOOR_KEY_7}
    #define KINETIS_FLASH_CONFIGURATION_PROGRAM_PROTECTION {PROTECTION_0, PROTECTION_1, PROTECTION_2, PROTECTION_3}
    #define KINETIS_FLASH_CONFIGURATION_SECURITY           (FTFL_FSEC_SEC_UNSECURE | FTFL_FSEC_FSLACC_GRANTED | FTFL_FSEC_MEEN_ENABLED | FTFL_FSEC_KEYEN_ENABLED)
    #if defined KINETIS_KL || defined KINETIS_KV
        #if defined KINETIS_KL03 || defined KINETIS_KL43
...
        #else
            #define KINETIS_FLASH_CONFIGURATION_NONVOL_OPTION  (FTFL_FOPT_LPBOOT_CLK_DIV_8 | FTFL_FOPT_RESET_PIN_ENABLED)
        #endif
    #else
        #if defined KINETIS_REVISION_2
            #if defined FRDM_K64F
                #define KINETIS_FLASH_CONFIGURATION_NONVOL_OPTION  (FTFL_FOPT_EZPORT_DISABLED | FTFL_FOPT_LPBOOT_NORMAL | FTFL_FOPT_NMI_DISABLED) // there is a large capacitor on the NMI/EzP_CS input so these are disabled to allow it to start with requiring an NMI handler or moving to EzPort mode
            #else
                #define KINETIS_FLASH_CONFIGURATION_NONVOL_OPTION  (FTFL_FOPT_EZPORT_ENABLED | FTFL_FOPT_LPBOOT_NORMAL | FTFL_FOPT_NMI_DISABLED)
            #endif
        #else
            #define KINETIS_FLASH_CONFIGURATION_NONVOL_OPTION  (FTFL_FOPT_EZPORT_ENABLED | FTFL_FOPT_LPBOOT_NORMAL | FTFL_FOPT_NMI_ENABLED)
        #endif
    #endif
#endif



You can also see that the NMI input is disabled since there is a big capacitor on the input which otherwise causes problems with starting when the OpenSDA is not powered.


Regards

Mark

48
NXPTM M522XX, KINETIS and i.MX RT / TEENSY LC Support Ready
« on: March 27, 2015, 08:42:52 AM »
Hi All

The new TEENSY LC (low cost), based on a Kinetis KL26 [64k Flash and 8k SRAM], is now supported in the uTasker project:
http://www.utasker.com/kinetis/TEENSY_LC.html

The link includes a simulation and images for USB-MSD and SREC loaders as well as application for 3xCDC UART bridge and composite USB-CDC / USB-MSD and SD card.

Regards

Mark


49
µTasker general / USB Composite Devices and USB Keyboard test
« on: March 02, 2015, 01:47:07 AM »
Hi All

For all interested in composite USB device operation there is a new page with details at
http://www.utasker.com/kinetis/USB_Device.html

This also includes a USB keyboard test that is integrated into the framework.

Regards

Mark


50
NXPTM M522XX, KINETIS and i.MX RT / Kinetis UART / LPUART Referencing
« on: February 22, 2015, 03:20:34 AM »
Hi All

 Kinetis devices originally contained a number of UARTs, with up to 6 available in some parts - such as the K60. More recently newer parts started appearing with LPUARTs (Low Power UARTs), for example the KL03 with a single LPUART. However some parts can also include both types, such as the KL43 with two LPUARTs plus a single UART, or the K22 with 3 UARTs and a single LPUART.

UARTs and LPUARTs have various differences and the question that arises when using a driver interface is how can they be handled in a generic manner so that appliation code is compatible as well as how are the channels numbered in the µTasker interface?

This subject is detailed at:  http://www.utasker.com/kinetis/UART_LPUART.html

Regards

Mark


51
µTasker general / USB-MSD firmware loading and MAC OS X compatibiity
« on: February 20, 2015, 06:08:15 AM »
Hi All

USB-MSD firmware loading has proven to be a very popular method for loading embedded firmware for a number or reasons, not least due to its cross-platform driverless capability.

However the OS manufacturers (Windows 8.1, MAC OS X) have been making life rather complicated with new behavior when external hard drives are connected.

The story behind the MAC OS X compatibility development in the uTasker serial loader is recorded here:
http://www.utasker.com/kinetis/USB-MSD-MAC.html

Regards

Mark


52
NXPTM M522XX, KINETIS and i.MX RT / Kinetis Port Macros
« on: February 19, 2015, 03:37:49 PM »
Hi All

Here is a complete list of Kinetis port macros which are compatible across all Kinetis (KE, KL, KV, K parts) apart from where an exception is noted.
The macros also contain simulator hooks and so when used the uTasker Kinetis simulator is ensured to remain synchronised to the present port states.
Note that many macros enable configuring/modifying multiple pins on a port at the same time.

Regards

Mark


// Configure pins as output, including enabling clock to specified port eg. _CONFIG_PORT_OUTPUT(A, (PORTA_BIT16 | PORTA_BIT8), (PORT_SRE_FAST | PORT_DSE_LOW));
//
_CONFIG_PORT_OUTPUT(ref, pins, chars)
_CONFIG_PORT_OUTPUT_FAST_LOW(ref, pins, chars) - version for faster configuring of lower 16 bits (not KE)
_CONFIG_PORT_OUTPUT_FAST_HIGH(ref, pins, chars) - version for faster configuring of upper 16 bits (not KE)

// Configure pins as Input, including enabling clock to specified port  eg. _CONFIG_PORT_INPUT(A, (PORTA_BIT4 |PORTA_BIT3 | PORTA_BIT2), PORT_PS_UP_ENABLE);
//
_CONFIG_PORT_INPUT(ref, pins, chars)
_CONFIG_PORT_INPUT_FAST_LOW(ref, pins, chars) - version for faster configuring of lower 16 bits (not KE)
_CONFIG_PORT_INPUT_FAST_HIGH(ref, pins, chars) - version for faster configuring of upper 16 bits (not KE)


// Configure a peripheral function eg. _CONFIG_PERIPHERAL(B, 2, (PB_2_FTM0_CH0 | PORT_SRE_FAST | PORT_DSE_HIGH));
//
_CONFIG_PERIPHERAL(port, pin, function)

// Write to a port with a mask eg. _WRITE_PORT_MASK(C, 0x1234,  0x0000ffff);
//
_WRITE_PORT_MASK(ref, value, mask)

// Write full port width _WRITE_PORT_MASK(C, 0x12345678);
//
_WRITE_PORT(ref, value)

// Toggle a port with a mask eg. _TOGGLE_PORT(D, PORTD_BIT3);
//
_TOGGLE_PORT(ref, mask)

// Read full port width eg. _READ_PORT(A);
//
_READ_PORT(ref)

// Read from a port with a mask eg. _READ_PORT(A, (PORTD_BIT3 | PORTD_BIT0));
//
_READ_PORT_MASK(ref, mask)

// Configure outputs, including enabling clock to specified port, and then set a value to them - this device sets the value and then drives
// eg. _CONFIG_DRIVE_PORT_OUTPUT_VALUE(C, (PORTC_BIT13 | PORTC_BIT0), (PORTC_BIT13), (PORT_SRE_SLOW | PORT_DSE_HIGH));
// - example configures two pins and synchronously sets these to '1' and '0' respectively
//
_CONFIG_DRIVE_PORT_OUTPUT_VALUE(ref, pins, value, chars)
_CONFIG_DRIVE_PORT_OUTPUT_VALUE_FAST_LOW(ref, pins, value, chars) - version for faster configuring of lower 16 bits (not KE)
_CONFIG_DRIVE_PORT_OUTPUT_VALUE_FAST_HIGH(ref, pins, value, chars) - version for faster configuring of upper 16 bits (not KE)


// Set from inputs to outputs and set a value to them - this is equivalent to _CONFIG_DRIVE_PORT_OUTPUT_VALUE on this device
//
_DRIVE_PORT_OUTPUT_VALUE(ref, mask, value)

// Set from outputs to inputs eg. _FLOAT_PORT(A, LCD_BUS_BITS);
//
#define _FLOAT_PORT(ref, pins)

// Set from inputs to outputs eg. _DRIVE_PORT_OUTPUT(A, LCD_BUS_BITS);
//
#define _DRIVE_PORT_OUTPUT(ref, pins)

// Set and clear individual bits of a port eg. _SETBITS(B, (PORTB_BIT5 | PORTB_BIT19)); / _CLEARBITS(B, (PORTB_BIT5 | PORTB_BIT19));
//
_SETBITS(ref, pins)
_CLEARBITS(ref, pins)


53
µTasker general / SSL/TLS Secure Connections
« on: January 28, 2015, 11:35:10 PM »
Hi All

With increasing interest in IoT (Internet of Things) and the associated aspects of security an investigation into adding an integrated SSL/TLS solution for connection oriented protocols (especially HTTP as used by the web server) has been initiated.

This can be followed at http://www.utasker.com/kinetis/secure.html

Please use this thread for any associated discussions.

Regards

Mark



54
Hi All

The latest boot loaders now include Freescale KBOOT [ http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=KBOOT ] firmware upload compatibility - see the Kinetis landing page for ready-built loaders for many Kinetis boards: http://www.utasker.com/kinetis.html

The KBOOT mode is optionally configurable on UART and/or USB but also works in parallel with the popular USB-MSD loading method (where the board appears as a hard drive and the new code can be dragged and dropped on to it).

Here are some new details which should help when working with the loaders which support various methods, but including USB-MSD.
One advantage of USB-MSD, even when no used as actual upload method, is that it can display the presently loaded software as well as offering a download of the software (password protected). The following list shows the way that the loaded firmware is displayed, depending on its original loading method:

- Loading SW via USB-MSD card results in a file with its origial name (can be long file name) with its original time and date.
- Loading SW via SD card results in a file called "SOFTWARE.BIN" with the time and date taken from the original file on the SD card.
- Loading as serial SREC results in a file called "SOFTWARE.S19" but with fixed date/time.
- Loading via AN2295 Develope's Serial Bootloader results in a file called "DEVELOPE.S19" but with fixed date/time.
- Loading via KBOOT UART results in a file called "KBOOTSER.BIN" but with fixed date/time.
- Loading via KBOOT UART results in a file called "KBOOTUSB.BIN" but with fixed date/time.
- Loading via web server results in a file called "WEB_LOAD.BIN" but with fixed date/time.
In each case the size matches the firmware size.

Regards

Mark

P.S. The uTasker Serial Loder document has been updated to refect the latest capabilities: http://www.utasker.com/docs/uTasker/uTaskerSerialLoader.PDF


55
Hi All

The trend continues to reduce power consumption in systems and the Kinetis processors offer interetsing and useful support to help achieve such goals.

The Low-Leakage Wakeup Unit is the topic of the Kinetis Developer's module at http://www.utasker.com/kinetis/LLWU.html

Please use this thread for discussion or feedback to this subject.

Regards

Mark

56
NXPTM M522XX, KINETIS and i.MX RT / Kinetis KL RTC
« on: January 03, 2015, 11:31:25 PM »
Hi All

The following article discusses the RTC in the KL devices, along with some related notes for SLCD clocking.

http://www.utasker.com/kinetis/KL_RTC.html

Regards

Mark

57
Hi All

The following is a guide for Teensy 3.1 Arduino/Teensyduino users to allow their application to be used together with the uTasker Serial Loader.

1. Determine the application address that the serial loader uses. This is 0x8080 in the pre-built version but can be changed when building with the uTasker Serial Loader project (this is because the serial loader includes SREC and USB-MSD loading and stores a file object at 0x8080 so that the name, date, time of the loaded application can be displayed and the address can be lower when less serial loader features are enabled).

2. Link your project to this address by modifying the linker script setting (in mk20dx256.ld) from
FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 256K
to
FLASH (rx) : ORIGIN = 0x00008080, LENGTH = 256K

3. Note that the uTasker serial loader will either disable or enable the watchdog (1s timeout) depending on the state of the input pin 21 [A6]. Left unconnected it will enable it and holding it to ground at reset will cause it to be disabled.
The Teensyduino code will also do something similar but this will fail due to the fact that its unlock sequence code is too slow when the processor has already been initialised. A reset would fire "during" the unlock sequence and so this code can't be used.
Therefore, since the watchdog has already been enabled/disabled in the serial loader, remove the following code from mk20dx128.c. It is also recommeneded to generally use an active watchdog to allow system recovery in case or errors during opertion and so the watchdog should be periodically retriggered by the application code.

   WDOG_UNLOCK = WDOG_UNLOCK_SEQ1;
   WDOG_UNLOCK = WDOG_UNLOCK_SEQ2;
   asm volatile ("nop");
   asm volatile ("nop");

   // programs using the watchdog timer or needing to initialize hardware as
   // early as possible can implement startup_early_hook()
   startup_early_hook();


4. Depending on which version of the Teensy project you are using its interrupt vectors will either be in Flash or in RAM (from Teensyduino 1.20 they should be in RAM). When in RAM there is nothing more to be done but when in Flash there are two choices, depending on the link address being used:

a. If the link address is divisible by 512 (eg. 0x2800, 0x8000 etc.) simply set the Cortex M4's vector table offset to match. That is, modify the line of code in mk20dx128.c from
SCB_VTOR = 0;
to
SCB_VTOR = 0x00008000; // this must match the link address of the application when interrupts are fixed in Flash

b. In the case of 0x8080 or other addresses that are not divisble by 512 (this is a Cortex M4 NVIC restriction) it is not possible to work with fixed vectors in Flash and so these must be moved to RAM, which is simply done by using these lines of code instead:
   SCB_VTOR = 0x1fff8000; // set the location of interrupt vectors to the start of SRAM
   memcpy((void *)0x1fff8000, 0x00008080, 0x200); // copy the fixed vectors to SRAM


Plus by editing another linker script file (mk20dx256.ld) entry from
RAM  (rwx) : ORIGIN = 0x1FFF8000, LENGTH = 64K
to
RAM  (rwx) : ORIGIN = 0x1FFF8200, LENGTH = 64K-0x200
in order to keep this area free for the usage.

Note that from Teensyduino 1.20 the vectors should already be in RAM and so this step is not required.



5. The Teensy 3.1 Arduino/Teensyduino build creates an Intel Hex output file. The uTasker Serial Loader generally works with SREC or Binary files and the standard output can be converted to one of these by using GCC's objcopy - it is simplest to create a bat file with the commands that can be executed after each project build. Assuming that the output from the build is a file called software.hex the following commands will create both SREC and binary versions form it. In addition, using the uTasker utility "uTaskerCombine" [ http://www.utasker.com/forum/index.php?topic=1445.0 ] a combined serial loader/aplication binary can be created that can then be loaded as a single file (loader plus application), which is useful for a production environment in order to be able to load one complete software rather than first the loader and then the first application.

objcopy --input-target=ihex --output-target=binary software.hex application.bin
objcopy --input-target=ihex --output-target=srec software.hex application.srec
uTaskerCombine uTaskerSerialLoader.bin application.bin 0x8080 file3.bin combinedLoaderApp.bin

Note that the application's start address must also match when combining the binary files

6. When working with SD card loading (rarer case with the Teensy) the software file loaded to the SD card needs an additional header for authentication (and can be optionally encrypted). To do this the uTasker utility uTaskerConvert is used (see the utilities link above). The command for the reference serial loader without encryption is
uTaskerConvert.exe application.bin software.bin -0x1234 -a748b6531124
For full details of adding authentication and encryption see chapter 8 of http://www.utasker.com/docs/uTasker/uTasker_BM_Loader.pdf


After making these adjustments you should find that the Teensy 3.1 Arduino/Teensyduino application in question can work at the offset link address and so operate in conjunction with the uTasker serial loader.

Regards

Mark


58
NXPTM M522XX, KINETIS and i.MX RT / Freescale FreeMASTER
« on: January 02, 2015, 01:21:51 PM »
Hi All

As Freescale device users you maybe still haven't discovered the FreeMASTER tool that Freesle offers(?)

For information about FreeMASTER and details of the uTaker FreeMASTER module integration please see http://www.utasker.com/kinetis/FreeMASTER.html

Regards

Mark

59
NXPTM M522XX, KINETIS and i.MX RT / Kinetis KE EEPROM
« on: December 31, 2014, 03:02:11 AM »
Hi All

The Kinetis KE family has recently been added to the uTasker project. The KE02Z (as on FRDM-KE02Z and FRDM-KE02Z40M Freedom boards) have 256 bytes of (sort of) EEPROM, which makes them quite unique since I haven't seen this in other parts (not without using EEPROM emulation in FlexNVM).

There are more details at http://www.utasker.com/kinetis/KE_EEPROM.html
and some binaries to experiment with at http://www.utasker.com/kinetis/FRDM-KE02Z.html and http://www.utasker.com/kinetis/FRDM-KE02Z40M.html

Regards

Mark

60
Hi Al

Since I often get the question as to how applications can be linked and their interrupts be configured so that they work with the uTasker Serial Loader I have copied a reference solution here. It is specific for the Freescale Kinetis (with PE generated linker script) but is quite general to ARM so I thought it best located in the general section.

Regards

Mark


Quote
1. You need to link your code to the start location of the application (eg. 0x8080). The following changes to the linker script should do it:

MEMORY {
  m_interrupts (RX) : ORIGIN = 0x00008080, LENGTH = 0x000001E0
  m_text      (RX) : ORIGIN = 0x00008290, LENGTH = 0x00040000-0x8290
  m_data      (RW) : ORIGIN = 0x1FFF0000, LENGTH = 0x00010000
  m_data_20000000 (RW) : ORIGIN = 0x20000000, LENGTH = 0x00010000
  m_cfmprotrom  (RX) : ORIGIN = 0x00008280, LENGTH = 0x00000010
}

Note that m_cfmprotrom is for flash configuration but is not useful for a boot loaded application since the boot loader determines the settings (see the "FLASH configuration settings" in the uTasker serial or "BM" loader in app_hw_kinetis.h)

2. The setting in 1. puts the reset vectors (and fixed interrupt vectors) at 0x8080. This address can't be used to operate them from because the Cortex M4 can only operate them on 512 byte aligned addresses. If you don't need the USB-MSD loader (which stores a file object in the first 0x80 bytes - and so uses 0x8080 rather than 0x8000 - and can use lower addresses like 0x2800 [check the size of the loader to see which lowest address is possible]) you can also use an aligned address instead. In such a case you can leave your interrupt vectors in Flash and you only need to add the following line of code to the application startup file:
SCB_VTOR = 0x8000;    // use vector table in flash at this offset (check the definition of SCB_VTOR since this example is from the Teensy3.1 Arduino project and your header files may spell it differently)

3. Generally it is preferred to locate the vectors in SRAM since they are then faster and can be swapped during run time if required. To do this you can leave space for them in SRAM by changing the linker script RAM setting:
  m_data      (RW) : ORIGIN = 0x1FFF0200, LENGTH = 0x00010000-0x200
so that the first 0x200 bytes are not used by the linker (they are then free for vector usage).

In the start up code simply copy the fixed ones from the code to here and then point the Cortex M4 vector offset register to them.

    memcpy((void *)0x1fff0000, (void *)0x8080, 0x200); // copy fixed interrupt vectors to the start of SRAM - assuming the project is linked to 0x8080, which is an invalid address for fixed vectors
    SCB_VTOR = 0x1fff0000;


Of course defines can be used rather than fixed values to make it portable but the example should be clearer like this.

Note that the uTasker project enters each interrupt when required by calling
extern void fnEnterInterrupt(int iInterruptID, unsigned char ucPriority, void (*InterruptFunc)(void));
eg. fnEnterInterrupt(irq_USB_OTG_ID, PRIORITY_USB_OTG, _usb_otg_isr); // enter and configure USB OTG interrupt
and so doesn't need to fix vectors in the code.

Pages: 1 2 3 [4] 5 6 ... 19