Recent Posts

Pages: [1] 2 3 ... 10
STTM STM32 and STR91XF / STM32F4xx Flash Options Video
« Last post by mark on December 01, 2018, 02:28:28 AM »
Hi All

The following video explains and demonstrates Flash Option settings for Flash Sector write protection and Flash read-out protection on the STM32F429 (valid or similar for various other STM32 processors too):

The binary used in the video is attached to this post for anyone wishing to try it themselves on a NUCLEO-F429ZI.


FreescaleTM 522XX and KINETIS / Re: [Kinetis KL03] Custom pin assignments
« Last post by mark on November 26, 2018, 08:11:23 PM »

The pin multiplexing details as given by the user's manual/data sheet are those that are present in the hardware.
One of these can be selected (as you know) but other combinations are not possible sine the chip don't physically support them.


FreescaleTM 522XX and KINETIS / [Kinetis KL03] Custom pin assignments
« Last post by Raffaele on November 26, 2018, 07:52:36 PM »
Hi all,

on page 48 of the Kinetis KL03 datasheet   the signals available on each pin are reported.

My question is: can I change this assignments?
Let's say I want to assign a timer TPM0_CH0 to PTB4 as ALT2 function. Now, ALT2 function is already assigned to PTB4 and it is an I2C0_SDA. Or I could also assign TPM0_CH0 as ALT4 since it is empty.

I know how to use the _CONFIG_PERIPHERAL to select the function that I want on a pre-assigned pin, but I don't know IF/HOW to reassign functions to a pin.
If this is possible, which function/registers do I need to change? And in which file are they?

Thank you
Hi All

Optional addition AES-256 strength encryption/decryption has been added to the KBOOT compatible (UART and/or USB-HID) modes of the serial loader. This can be seen in this new video:

The encryption is performed by the new version of the the uTaskerConvert V1.11 utility:



µTasker general / Re: Last CodeWarrior version using uTasker 1.3v
« Last post by mark on October 26, 2018, 09:17:22 PM »

As long as you can still get the Coldfire parts (and at a reasonable price) you can continue maintaining the product with the original firmware.

Sometimes (which seems to be happening at the moment with some older lines) a design in of a new part can't be avoided (eg. the original ones are no manufactured any more and no more reliable stock can be found). The natural migration for the Coldfire V2s are to Kinetis (but beware that there is no part with internal Ethernet PHY) and this is very easy when the product already uses uTasker since the application / hardware interface is highly compatible. Existing Coldifre projects can often be ported to Kinetis within a few hours without much need to get to know the Kinetis details. Pin for pin compatibility is usually not possible, so some HW modification is needed though.

Semiconductor manufactures tend to guarantee supply during 10..15 years, which gives a period where supply can more or less be relied on. In practice products are often still manufactured after this time and so a route to update should be incorporated in the general engineering cycle. At the moment of writing it is becoming almost impossible to source Luminary or ST Micro STR92x parts and so there is a wave of product upgrades where these were used.

The uTasker project (being independent) has always had the goal of intensively supporting certain parts but still keeping the application open to the use of different processors. Whereas products developed using semiconductor libraries become very locked in to the manufacture due to the fact that quite details knowledge of the chips and their HW application interface are needed, or reliance on certain code generation tools are present, when the chips gets old and their prices spiral it is difficult to escape due to the high engineering cost/risk involved to move to completely new libraries. uTasker developments can be moved efficiently and cheaply (no lock in) when this situation arrives or when better supported alternatives (also from other manufacturers) are identified, or when supply chain (lead times) makes it necessary to make a change.


µTasker general / Re: Last CodeWarrior version using uTasker 1.3v
« Last post by Genisuvi on October 26, 2018, 09:50:18 AM »
I'm so sorry Mark, I just copied a msg tried to be sent before. The email problems refered last line should not be posted. It's solved. The emailing problem was detected in my company email account configuration.

Thank you very much for your quick step guide. I hope it works. I will try to follow your steps.

I agree with you. I 'm also think that one of the solution to avoid future obsolescences is the hardware migration. But it could take more things and work into account: if there is a newest mcu that matches with our current mcu, pinout rerouting pcb, pinout new code configurations and new registers to be writen, peripheral control modifications, functionality testing, etc.. However, I think it will be a point in which this will become the only solution that allows the fw production maintainance, furthermore if Nxp production quit off the micro someday. So It's requires some analysis before, I'm go to start to win some bits of time trying the first quick solution.

Best regards.
µTasker general / Re: Tools that might be of interest to uTasker users
« Last post by mark on October 25, 2018, 11:35:03 PM »
Thanks Martin

You have been an ambassador for use of COM0COM UART loop back simulation.
I just point people to your posts and they simply start working with it to do their projects.

What still surprises me after all these years is that various uses or it essentially simplify development and testing and accelerate projects on a regular basis, but it seems still the majority of firmware developers remain ignorant of the (vast) simulation advantages and still take longer than necessary to complete work (and cost their companies more time and money that would be necessary).


µTasker general / Re: Last CodeWarrior version using uTasker 1.3v
« Last post by mark on October 25, 2018, 11:26:16 PM »

You can try adding the content of the attached zip file "" to the root directory of your uTaskerV1.3 project (that is the directory which contains \Applications \uTasker, \Hardware, etc.). This should allow you to import your project into CodeWarrior 10.
Also add the content of the second attached zip file "" to the folder "\Applications\uTaskerV1.3", or your own application location (it supplies linker scripts and is the location used for output objects).
Then you should change any paths that you find which reference uTaskerV1.4 to uTaskerV1.3 or your own location.
If all works out you will then be able to build the project (make sure the correct processor and linker script is selected in CW10).
The following overview may be helpful:

The other possibility is to use the uTaskerV1.4 version and put your application into its \Applications directory. uTaskerV1.4 contains also the CW10 project so you should be able to build yours with it. V1.4 is more or less backward compatible with V1.3. See for a few details.

I am not aware of any problems with the email addresses but I see that you had also problems sending to my person address, with the error message that "Relay Access was denied" for all. Your company also contacted me at the same address to inform me of this (without problems) which suggests that the difficulty is related to your email account settings. I think the relay access denial occurs when you use a different output server to send messages from than the one that you account is attached to and some servers may not allow this or the destination will reject it.

The uTasker project is now 14 years old and still includes Coldfire V2 support in its project but this tends to be used only rarely for maintenance of legacy projects. After 2011 most Coldfire users switched over to Kinetis parts instead.



µTasker general / Last CodeWarrior version using uTasker 1.3v
« Last post by Genisuvi on October 25, 2018, 03:19:49 PM »
The project in which I'm working is an industrial applicaction project based on based on coldifre (mcf52259) and it's built using uTasker v1.3 with an old codewarrior version (5.9; although when you click in help button you can read: CW DS for CF Arch 7.2) some time ago.

Currently this CW IDE version is installed in a computer within windows XP OS. But debugging has never worked; the IDE hangs. And XP Ws is totally obsolete, as you know, out of official support.

I would like to install a newer CW version in a computer with windows 10, loading the whole application files, creating the project, being able to compile files and make the fw bin files with the minimum code modifications. So, porting the project.

I know that last versions of CW are not supporting uTasker v1.3, so they may be using the v1.4. But I would like to know if here is anyone who knows what is the last CW version compliant with uTasker 1.3v using the same MCU. I don't need the newest CW version, but some version newest than CW5.9 could be fine to check if debugging is possible, also running out of windows XP operating system.

I was trying to find more information about this kind of question and I also was trying to contact someone in uTasker project, but its web seems to be disabled and contact emails too. I don't know if uTasker project is stopped or I was visiting the wrong link.

Any information will be apreciate and it will be helpful.

Best regards.
µTasker general / Tools that might be of interest to uTasker users
« Last post by mhoneywill on October 25, 2018, 11:57:16 AM »
Below is a list of windows based tools that might be of interest to uTasker users, these are tools that I have used before

Virtual Serial Ports
Source files
Signed drivers
Run the setupc.exe program then type
"install portname=com10 portname=com11" to create a virtual com port pair linked together

Below is the help text from setupc.exe

Setup for com0com

  [options] <command>

  --output <file>              - file for output, default is console
  • <to>               - wait <to> seconds for install completion. If

                                 <to> has '+' prefix then ask user to continue
                                 waiting after <to> seconds elapsing
                                 (by default <to> is 0 - no wait)
  --detail-prms                - show detailed parameters
  --silent                     - suppress dialogs if possible
  --no-update                  - do not update driver while install command
                                 execution (the other install command w/o this
                                 option expected later)
  --no-update-fnames           - do not update friendly names
  --show-fnames                - show friendly names activity

  install <n> <prmsA> <prmsB>  - install a pair of linked ports with
   or                            identifiers CNCA<n> and CNCB<n>
  install <prmsA> <prmsB>        (by default <n> is the first not used number),
                                 set their parameters to <prmsA> and <prmsB>
  install                      - can be used to update driver after execution
                                 of install commands with --no-update option
  remove <n>                   - remove a pair of linked ports with
                                 identifiers CNCA<n> and CNCB<n>
  disable all                  - disable all ports in current hardware profile
  enable all                   - enable all ports in current hardware profile
  change <portid> <prms>       - set parameters <prms> for port with
                                 identifier <portid>
  list                         - for each port show its identifier and
  preinstall                   - preinstall driver
  update                       - update driver
  reload                       - reload driver
  uninstall                    - uninstall all ports and the driver
  infclean                     - clean old INF files
  busynames <pattern>          - show names that already in use and match the
                                 <pattern> (wildcards: '*' and '?')
  updatefnames                 - update friendly names
  listfnames                   - for each bus and port show its identifier and
                                 friendly name
  quit                         - quit
  help                         - print this help

Syntax of port parameters string:
  -                       - use driver's defaults for all parameters
  *                       - use current settings for all parameters
  <par>=<val>[,...]       - set value <val> for each parameter <par>

  PortName=<portname>     - set port name to <portname>
                            (port identifier by default)
  EmuBR={yes|no}          - enable/disable baud rate emulation in the direction
                            to the paired port (disabled by default)
  EmuOverrun={yes|no}     - enable/disable buffer overrun (disabled by default)
  EmuNoise=<n>            - probability in range 0-0.99999999 of error per
                            character frame in the direction to the paired port
                            (0 by default)
  AddRTTO=<n>             - add <n> milliseconds to the total time-out period
                            for read operations (0 by default)
  AddRITO=<n>             - add <n> milliseconds to the maximum time allowed to
                            elapse between the arrival of two characters for
                            read operations (0 by default)
  PlugInMode={yes|no}     - enable/disable plug-in mode, the plug-in mode port
                            is hidden and can't be open if the paired port is
                            not open (disabled by default)
  ExclusiveMode={yes|no}  - enable/disable exclusive mode, the exclusive mode
                            port is hidden if it is open (disabled by default)
  HiddenMode={yes|no}     - enable/disable hidden mode, the hidden mode port is
                            hidden as it is possible for port enumerators
                            (disabled by default)
  AllDataBits={yes|no}    - enable/disable all data bits transfer disregard
                            data bits setting (disabled by default)
  cts=[!]<p>              - wire CTS pin to <p> (rrts by default)
  dsr=[!]<p>              - wire DSR pin to <p> (rdtr by default)
  dcd=[!]<p>              - wire DCD pin to <p> (rdtr by default)
  ri=[!]<p>               - wire RI pin to <p> (!on by default)

The possible values of <p> above can be rrts, lrts, rdtr, ldtr, rout1, lout1,
rout2, lout2 (remote/local RTS/DTR/OUT1/OUT2), ropen, lopen (logical ON if
remote/local port is open) or on (logical ON). The exclamation sign (!) can be
used to invert the value.

Special values:
  -                       - use driver's default value
  *                       - use current setting

If parameter 'PortName=COM#' is used then the Ports class installer will be
invoked to set the real port name. The Ports class installer selects the COM
port number and sets the real port name to COM<n>, where <n> is the selected
port number. Thereafter use parameter RealPortName=COM<n> to change the real
port name.

  install - -
  install 5 * *
  remove 0
  install PortName=COM2 PortName=COM4
  install PortName=COM5,EmuBR=yes,EmuOverrun=yes -
  change CNCA0 EmuBR=yes,EmuOverrun=yes
  change CNCA0 PortName=-
  busynames COM?*

File Comparison

Standalone DHCP server for windows

CURL windows file transfer
(Useful for downloading files to utasker projects)
Pages: [1] 2 3 ... 10