Topics

61

µTasker general / Installing unsigned drivers on Windows 8.1

« on: December 26, 2014, 03:06:16 AM »

Hi All

If you have recently moved to Windows 8.1 and need to install a USB driver (such as the USB-CDC driver, or your own, or an old one that you have used for some time and trust) but Windows says that it failed due to it not being digitally signed you will need to restart the PC first in a mode that allows installing them as older Windows versions did (with warning - "install the software anyway").

The following video shows how it is done: https://www.youtube.com/watch?v=UPm_6aejOlo

Regards

Mark

62

µTasker general / IAR 7.3 ARM Optimisation error

« on: December 24, 2014, 07:59:02 PM »

Hi All

It has been identified that from IAR 7.3 ARM  (probably, since that is when the problem started to be noticed) operation can become unreliable or fail due to an optimisation error. This takes place when the optimiser identifies code where it can insert __aeabi_memset() to improve performance (see http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka3934.html).

The failure takes place in code like this:

    while (Size--) {
        *ptr++ = ucValue;
    }

where the IAR optimiser replaces it with
MOVS R2, R1
SUBS R1, R0, #1
MOVS R0, R4
BL __aeabi_memset

When debugging the code it is seen that Size is 0x28 (in a test instance), which is in register R2. The destination pointer address is in R4.
The count value is decremented by 1 and then it and the pointer are passed to the optimised __aeabi_memset() in registers R1 (0x27) and R0 (destination pointer). The error is that the decremented count value is passed to the library routine whereas it should not be decremented in this situation.

The result is that 0x27 bytes are set with the value instead of 0x28. The result can have serious concequences since it leaves the final byte at an uninitialised value (random).

This is being reported to IAR, whereby it is to note that the problem was not known in previous versions (not reported by users or not noticed as effect) and also all other tests with other compilers have not shown a similar issue.

In the mean time it is recommended to use "medium" optimisation rather than "high" since with medium the substitution is not made and the operation is then correct. The resulting code size increase is about 6%.

Regards

Mark

63

µTasker general / Problems importing Eclipse projects (eg. Codewarrior 10.x, KDS)

« on: August 29, 2014, 03:16:54 PM »

Hi All

There have been a few cases reported of difficulties importing Eclipse based projects so I though it worth reporing a possible reason here that is a little surprising.

The uTasker project is distributed as a ZIP file and it has been found that some ZIP extraction programs (certainly ones of MACs, where his problem originated from) exract files beginning wih a '.' (do) as invisible files (somehing to do wih Unix I have heard) and so some Eclipse project files in the main directory (Eclipse names some of ist project files like this) can't be seen when trying to import the project (just doesn't recognise it as a project).

After extracting the project from the ZIP file using different tools (or not on a MAC) the files were visible and so the project could be imported as normal.

Just a "heads-up" in case something strange occurs like this ...

Regards

Mark

64

µTasker general / MOVED: preprocessor macro _CONFIG_DRIVE_PORT_OUTPUT_VALUE_FAST_HIGH

« on: May 15, 2014, 02:05:55 PM »

This topic has been moved to Freescale^TM 522XX and KINETIS.

http://www.utasker.com/forum/index.php?topic=1846.0

65

NXP^TM M522XX, KINETIS and i.MX RT / Freescale Kinetis Design Studio (KDS)

« on: May 04, 2014, 09:13:41 PM »

Hi All

Freescale has now made their new KDS available.

This is an environment for Kinetis development which is free and unlimited so will certainly become the main-stream IDE  in the future, replacing Freescale's CodeWarrior which has been the preferred IDE up to now.

After spending the weekend working with it, I conclude that it has no major problems so I have already made a Kinetis release with KDS support that defaults to it and the new FRDM-K64F board (V1.4.5): http://www.utasker.com/forum/index.php?topic=1721.0

I posted my experience at the new KDS forum: https://community.freescale.com/thread/323324
where there is a lot of additional information for getting started with this tool. My advice is to begin using it asap ;-)

Regards

Mark

66

NXP^TM M522XX, KINETIS and i.MX RT / I2C device dead-lock recovery (Kinetis)

« on: April 26, 2014, 05:45:08 AM »

Hi All

While working on a FRDM-KL25Z and continuously reading the accelerometer data via I2C bus I noticed that when powering the board it was always reliable, but when resetting the board (commanded reset or reset button) there was quite a high chance that the I2C bus would be blocked.

The reason for this is due to the fact that the accelerometer reading (4 bytes) is taking place using continuous repeated-start mode and the slave device is practically sending an acknowledgement about 15% of the time. If the reset button is pressed during the time that the accelerometer is sending the I2C ACK it will block in that state and continue driving the SDA line. After the reset is is not possible to use the I2C bus since it is continuously in the busy state and further resets of the processor don't help - a power cycle does however since it resets the slave device.

In the mentioned case the risk of this state was very high and so a reliable solution was investigated that would automatically detect the state and resolve.

The solution is as follows:

- rather than configure the I2C pins when the I2C interface is initialised they are left as inputs with pull-ups enabled

- the first time that the I2C bus is to be used for transmission (transmission takes place as first operation of any read or write) the bus state is checked.

- if it is detected in the busy state, the SCL pin is set to an output and clocks generated until the busy state no longer exists (the clocks remove the slave from its present ACK state - several clocks may be required)

- the pins are then set to their final I2C peripheral usage

- once the pins are set no further checking is required for subsequent I2C use and normal interrupt or DMA driven modes are possible

 
The result was that, although the I2C slave was still holding the bus in about 15% of reset cases, the automatic detection/recovery reliably resolved it with no user code intervention.

 
This is now included as integral part of the uTasker I2C driver code - for reference, the detection/recovery code for the pins as used by the accelerometer on the KL25 freedom board is show below.
 

In case of interest in trying this, I have attached a binary for the FRDM-KL25Z which continuously reads the accelerometer via I2C - no pauses). If the SDA line is measured when the reset button is held down it will be seen that the bus busy state is reprocuced often - subsequent recovery is 100%. The accelerometer values are printed to the UART (via OpenSDA virtual COM) ever 100th reading (about 4x per second).

 

Regards

 

Mark

 

Pin configuration during I2C initialisation is restricted to ensuring they are inputs:

_CONFIG_PORT_INPUT_FAST_HIGH(E, (PORTE_BIT25 | PORTE_BIT24), (PORT_ODE | PORT_PS_UP_ENABLE));

 

On first use the following code checks the bus state and recovers if neede, followed by setting the final peripheral pin functions:

 

while (_READ_PORT_MASK(E, PORTE_BIT25) == 0) {   // if the SDA line is low we clock the SCL line to free it

    _CONFIG_DRIVE_PORT_OUTPUT_VALUE_FAST_HIGH(E, PORTE_BIT24, 0, (PORT_ODE | PORT_PS_UP_ENABLE)); // set output '0'

    fnDelayLoop(10);

    _CONFIG_PORT_INPUT_FAST_HIGH(E, PORTE_BIT24, (PORT_ODE | PORT_PS_UP_ENABLE));

    fnDelayLoop(10);

}

_CONFIG_PERIPHERAL(E, 25, (PE_25_I2C0_SDA | PORT_ODE | PORT_PS_UP_ENABLE)); // I2C0_SDA on PE25 (alt. function 5)

_CONFIG_PERIPHERAL(E, 24, (PE_24_I2C0_SCL | PORT_ODE | PORT_PS_UP_ENABLE)); // I2C0_SCL on PE24 (alt. function 5)

67

NXP^TM M522XX, KINETIS and i.MX RT / New Kinetis KL/K package Quick Start guide for CodeWarrior video

« on: April 21, 2014, 04:55:38 PM »

Hi All

There is a new video giving quide available showing how to import the uTasker Kinetis project to CodeWarrior and then configure the project and compiler settings to match the device type to be used and the board type that it is on:

http://youtu.be/uBbiw36Caq4

Regards

Mark

68

NXP^TM M522XX, KINETIS and i.MX RT / Freescale FRDM-K64F

« on: April 08, 2014, 09:17:54 PM »

Hi All

Freescale has just introdued a low cost, high powered Freedom board - the FRDM-K64F:

It costs about $28 at the distributors and offers:


    Freescale K64F Kinetis K64 MCU (MK64FN1M0VLL12)
        High performance ARM® Cortex™-M4 Core
        120MHz, 256KB RAM, 1MB FLASH
        SPI (3)
        I2C (3)
        UART (6)
        USB OTG / Host / Device
        USB
        PWM
        ADC (2x 16bit with mux)
        DAC (2x 12bit)
        Touch Sensor
        GPIO

    FRDM-K64F Onboard Additions
        FXOS8700CQ - 3-axis accelerometer and magnetometer
        Ethernet
        2 push buttons
        RGB LED


http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=FRDM-K64F&fsrch=1

This is what Freescale calls a next generation Kinetis.

It certainly packs in functionality with a good price tag!

Regards

Mark

69

ST^TM STM32 and STR91XF / bxCAN Driver added to STM32 project

« on: March 09, 2014, 04:01:59 PM »

Hi All

Please note that the version V1.4.2 of the STM32 project contains CAN drivers for the bxCAN.
The updated CAN document http://www.utasker.com/docs/uTasker/uTaskerCAN.PDF includes details about its implementation, especially concerning its filter bank use and remote message realisation.

Regards

Mark

70

NXP^TM M522XX, KINETIS and i.MX RT / Kinetis KL family

« on: January 29, 2014, 03:19:16 AM »

Hi All

I have been working with the Kinetis for about 3 years now and have found them to be great devices. This, and the fact that many new projects use them, has meant that a lot of work has been focused in the Kinetis direction.

Recently I noticed that many Kinetis uses (at the freescale forums) are using KL types. These don't have Ethernet and are not quite as powerful (Cortext-M0+ core that than Cortex M4) but do have USB, SLCD controller and some a decent amount of Flash and SRAM, and are intended for (very) low power applications.

So I ordered various boards - Tower kits and Freedome boards; the Freedom boards are very cheap and I suppose this is why I have seen so much activity with them.

The devices are quite compatible (with the K family), which means that it was fairly simple to get projects with USB and SLCD (and UARTs) running. But there are various registers that have the same names but do have some different content. Some peripherals have reduced functionality - or even some addition features, which means all details need to be worked through (and tested). For example, I only realised today that my device was running with a different bus frequency than expected (yesterday all looked good because UART0 has a different clock source in the KLs), due to a register content difference.

It will take some time to work through all periperals but I will be putting the KL support in the next release so that the popular boards can be worked with.
Note that I have already put some KL46 USB-boot loader software on-line at http://www.utasker.com/SW_Demos.html#KL46

Regards

Mark

71

µTasker general / New uTasker Video showing Flexible Boot Loader

« on: December 20, 2013, 09:36:34 PM »

Hi All

http://youtu.be/XVlCisUmJMI

This video shows the Freescale K60 Tower kit with a flexible boot loader that supports SREC UART, SD Card and also USB-MSD at the same time.

Software package available on the SW/Live Demos page. http://www.utasker.com/SW_Demos.html#KINETIS

Flash requirement about 25k.

Regards

Mark

72

NXP^TM M522XX, KINETIS and i.MX RT / Codewarrior 10.5 (Kinetis)

« on: December 14, 2013, 01:15:26 AM »

Hi All

If anyone moves to CW10.5 (Kinetis) and finds that the linker fails please make the following modification:

In C/C++ Build -> setting -> ARM Linker -> Input -> Linker Command File

Change
"${APPLICATION_LOC}"/Project_Settings/Linker_Files/MK60N512VMD100_flash.lcf

To (notice the removal of the “” around the application location)
${APPLICATION_LOC}/Project_Settings/Linker_Files/MK60N512VMD100_flash.lcf

There is a setting for each target so it needs to be changed for each one used.

Regards

Mark

73

µTasker general / SD Card Boot Loader

« on: November 25, 2013, 11:45:14 PM »

Hi All

Most projects have included an SD Card Boot Loader for some time but without complete documentation to its use.

This has now been rectified in the latest Serial Loader Guide http://www.utasker.com/docs/uTasker/uTaskerSerialLoader.PDF which also includes the SD Card Boot Loader guide.

Attached is an updated version of SDLoader.c:

1. A new define should be added to Loader.h
#define MAX_WAIT_SD_CARD              5
This defines the longest period of time (in seconds) that the SD card loader will try to mount an SD card before starting an "available" application in Flash.

2. In SDLoader.c this limit is used and an available application will always be started in case an update is not possible – rather than remaining in the SD card loader. In the original version it was possible to remain in the SD card loader in certain situations.
 
3. It is also advisable to control the SD card loader from the card detect switch if the SD card socket has one (see page 21/27 of the guide for details).

Regards

Mark

74

NXP^TM M522XX, KINETIS and i.MX RT / Potential Problem mit IAR and Kinetis

« on: June 24, 2013, 04:10:49 PM »

Hi All

Today the Kinetis project wouldn't run when build with IAR and loaded to Flash (in SRAM it was OK).

The part was selected correctly (Freescale MK60DN512xxx10) but when debugging it was seen that the code was causing an exception when the IAR initialisation was being performed (in __iar_program_start()) and looked to be Floating Point Unit related.

Looking at the general options setting for the target the chip type was correct and below it the options were greyed out but the FPU setting was on "VPFv4". So I set the target to M4 core so that I could set this to "None". Then I set the target back to Freescale MK60DN512xxx10, rebuilt and the problem was gone.

Thsi suggest sthat the FPU setting can get 'stuck' when changing between types with and without this option. The IAR initialisation code presumably then has some additional FPU code added to it which causes an access which results in an exception so that the processor can't start.

The workaround/cure is however quite simple as noted above.

Regards

Mark

75

NXP^TM M522XX, KINETIS and i.MX RT / Setting Device Type for CW10.x Flash programming

« on: February 24, 2013, 04:00:21 AM »

Hi All

One of the most frustrating things that needs to be done with CW10 when programming a new device type is setting up the Flash programmer to match the new part.

Setting the new part is of course not the actual difficulty since it means simply selecting the required part's flash configuration file, but the problem is that when the window is opened to do this it is pointing to some path in the local project and one has to first identify where the part configurations are found.

To do this involves searching for the CW program install directory (quite easy) and then finding the .xml file matching the device - this is where it gets tricky. There are hundreds, if not thousands, of .xml files in the program directors and even multiple ones with names matching the parts that needs to be programmed and identifying the correct ones (in the correct directory) can be a source of much lost time.

This is a reference for myself to where the Kinetis flash configurations are found in the program directory (since I just changed to a new part and again had to spend 20 minutes trying to work out where they are again...)

C:\Freescale\CW MCU v10.2\MCU\bin\plugins\support\TargetTask\Flash_Programmer\ARM

Next time I'll be able to look it up here instead...;-)

Regards

Mark