Author Topic: uTasker V1.4 for M522XX now available  (Read 13054 times)

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
uTasker V1.4 for M522XX now available
« on: August 02, 2009, 09:34:36 PM »
Hi Coldfire users

I would like to inform you that there is a new uTasker version V1.4 available for the M522XX (M521X, M521XX, M5221X, M5222X, M5223X, M5225X).
This version includes latest new features:
-   User files - http://www.utasker.com/docs/uTasker/uTaskerUserFiles.PDF
-   Graphical LCD - http://www.utasker.com/forum/index.php?topic=636.0
as well as many improvements which can be read in the file headers if necessary.
-      SREC-Serial Loader project - http://www.utasker.com/docs/uTasker/uTaskerSerialLoader.PDF
                                                                      
One of the reasons for creating a version V1.4 is due to slightly different formatted string routines, which is described here: http://www.utasker.com/forum/index.php?topic=641.0 but also due to the fact that V1.4 is a larger synchronization of all uTasker target projects to a compatible state, with new port macros (aiding GPIO access and also easing moving between targets: see M5223x.h and search for “port macros” to see the macro set). All file headers have also be modified to reflect a new office address, whereby also newest sources have been integrated, improving code layout (more consistent) and correcting as many comment typos as have been found during the last year or so.
Specifically the file application.c was getting rather large and difficult to work with so a number of demos originally integrated into this file have been included via header files (such as application_lcd.h or Port_Interrupts.h). This makes application.c much smaller and easier to review but also keeps all peripheral tests, which have simply been removed to specific headers (containing code); it may appear a little strange at first but it does in fact work well like that after a small amount of practice.

The uTaskerV1.4 package also introduces a MODBUS extension pack which is compatible with this version (can be dropped in to work with (almost) all supported processors) – see http://www.utasker.com/forum/index.php?topic=635.0 and http://www.utasker.com/forum/index.php?topic=580.0 for more details and to review its user’s guide.

All registered users will receive an email containing the link to the new package as well as a new Coldfire password for the M5223X project.

The uTasker M522XX tutorials have been revised for the V1.4 release: http://www.utasker.com/docs/M5223X/uTaskerV1-4_M522XX.PDF and http://www.utasker.com/docs/M5223X/uTaskerV1-4_M5225X.PDF (specific for Kirin3)
I hope that you find the new software of interest and use – just use the forum in case of problems, questions or and other comments.


Good luck

Regards

Mark

« Last Edit: August 03, 2009, 12:33:13 AM by mark »

Offline tr111

  • Jr. Member
  • **
  • Posts: 72
    • View Profile
Re: uTasker V1.4 for M522XX now available
« Reply #1 on: August 05, 2009, 03:28:41 PM »
GOOD!THANK YOU!

Offline jezc

  • Jr. Member
  • **
  • Posts: 62
    • View Profile
Re: uTasker V1.4 for M522XX now available
« Reply #2 on: August 09, 2009, 08:26:59 AM »
Hi Mark,

I've not had an e-mail regarding the v1.4 release for this (but I have for the LPC23xx & SAM7x ports).

Can you please send the information for downloading the updated files?

Many thanks,

JezC

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: uTasker V1.4 for M522XX now available
« Reply #3 on: August 09, 2009, 11:15:36 AM »
Hi Jez

I just checked and see that your email address is in the SAM7X and LPC2XXX user groups but not in the M522XX user group.
This has now been corrected and the email just sent.

On a side note, in case any one else has missed receiving the update, there are always some emails that don't make it to their receivers due to people moving jobs and changing addresses, etc. I do keep a list of these but it would not be a good idea for me to publish them. Instead, if you think that you missed something just drop me a note informing me of new details and then I will ensure that it the information is updated and the lost mail will be resent.

Regards

Mark


Offline jezc

  • Jr. Member
  • **
  • Posts: 62
    • View Profile
Re: uTasker V1.4 for M522XX now available
« Reply #4 on: August 10, 2009, 10:13:02 AM »
Hi Mark,

I've got the information now - many thanks for sorting that out!

Looking forward to trying out the new additions!

Cheers,
    Jez

PS - When do you think you'll be looking to add support for the MCF51CN (V1 ColdFire core with Ethernet)? I've just got my hands on the tower system for one of these ;-)

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: uTasker V1.4 for M522XX now available
« Reply #5 on: August 10, 2009, 12:30:02 PM »
Hi Jez

MCF51CN - that is a good question.
You may have noticed that the AVR32 was added recently. It is very much like the ATMEL SAM7X and so fits well for the ATMEL SAM7/AVR32 families, making project movement between the two really easy.
There are three candidates for a further port (if it gets that far); STM32 connectivity range from ST, NXP LPC17XX (both CortexM3 based) and Coldfire V1 (where the MCF51CN gives the impetus for this).
The Coldfire V2 MCU is the most popular uTasker project and a single solution for both V2 MCU and V1 may be interesting. I known that the Freescale MQX solution is also being ported to the V1 but I have the feeling that it is really too heavy weight (in comparison to the uTasker solution) to be well suited - I will watch developments and talk with Freescale some more - but nothing decided just yet...

Regards

Mark

Offline luizpedrini

  • Newbie
  • *
  • Posts: 9
    • View Profile
    • Cianet Networking
Re: uTasker V1.4 for M522XX now available
« Reply #6 on: September 03, 2009, 07:04:57 PM »
Hi Mark,

I´m already being using the uTasker 1.3 and now changing to 1.4. At the same time I´m changing from CodeWarrior 6.3 to 7.0.

When i make the uTasker project all works fine, but, with the bootloader project I am not able to get the .elf file to program the M5223 device. Can this be a misconfiguration or some problem in CodeWarrior or i´m missing something on uTasker?

Thanks

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: uTasker V1.4 for M522XX now available
« Reply #7 on: September 03, 2009, 07:24:33 PM »
Hi

I know of some people using the V1.4 and CW7.X together with the boot loader but not heard of a difficulty in loading the elf file.
Therefore I don't think that it will be neither due to the V1.4 nor the CW7.x.

I find it easier to work with the SREC files created to check that the code is really at the start address expected. It is also easy to combine the SRECs (boot and application into one single SREC (eg. take the application as reference and copy the content of the boot to it (removing the first and last line of the boot SREC content) - put it to just after the first line in the application SREC file.

See whether it then loads normally and or course runs normally.
I have noted the the boot loader is set up for encryption as delivered in V4 so disable that if you are not working with encryption (although this has nothing to do with the elf loading).

Regards

Mark


Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: uTasker V1.4 for M522XX now available
« Reply #8 on: September 14, 2009, 07:20:11 PM »
Hi All

This is patch list collected since the release of V1.4. Check this when starting with the V1.4 package in case of any know issues.

1) CW 7.1.2. This is not an issue with the V1.4 package but a problem identified with the V1.4.2 CW patch. See http://www.utasker.com/forum/index.php?topic=659.0 (CW7.1.1 is the recommended version or else the workaround solves the known error, but it has also been reproted that similar errors have cropped up in project application code, so best avoid)


2) Start up file for Bare-minimum SPI FLASH configuration: http://www.utasker.com/forum/index.php?topic=654.msg2830#msg2830

3) GNU boot-loader project required a correction as detailed in the following thread: http://www.utasker.com/forum/index.php?topic=675.msg2956#msg2956

4) The detailed chip type settings for use of the random number generator in Kirin3 chips is not correct for M52252, M52254, M52256 and M52258. See the following for the correction, as well a general configuration improvement needed to solve the problem:
http://www.utasker.com/forum/index.php?topic=693.0

5) Random number generator error can be corrected as pointed out by Dave here: http://www.utasker.com/forum/index.php?topic=702.msg3049#msg3049

6) LAN_REPORT_ACTIVITY bug.

In fnEthernetEvent() in M5223x.c remove the lines labeled {113}. This was causing the interrupts to remain blocked - they were automatically opened again as soon as the frame had been handled, but this is not optimal.

#ifdef LAN_REPORT_ACTIVITY
      //iInterruptLevel = 1;                                             // {113} ensure interrupts remain blocked when putting message to queue
        fnWrite(INTERNAL_ROUTE, (unsigned char*)EMAC_int_message, HEADER_LENGTH);// inform the task of event
      //iInterruptLevel = 0;                                             // {113}
#endif



7) I2C bug.
If a new telegram is send by the application in exactly the time between the previous telegram's command to send the STOP condition and the bus becoming free (quite a short period of maybe a hundred CPU clocks or so) the second telegram's interrupt blocks. The following protects against it by waiting if the state is recognised:

In fnTxIIC() in M5223x.c.


    if (ptIICQue->ucState & TX_ACTIVE) {                                 // restart since we are hanging a second telegram on to previous one
        *register_ptr = (IIC_IEN | IIC_IIEN | IIC_MSTA | IIC_MTX | IIC_RSTA);
    }
    else {
        register_ptr += sizeof(unsigned long);                           // {116} move to status register
        while (*register_ptr & 0x20) {}                                  // {116} wait until the stop has actually been sent to avoid a further transmission being started in the mean time
        register_ptr -= sizeof(unsigned long);                           // {116} move back to CR
        *register_ptr = (IIC_IEN | IIC_IIEN | IIC_MTX);                  // set transmit mode with interrupt enabled
        *register_ptr = (IIC_IEN | IIC_IIEN | IIC_MSTA | IIC_MTX);       // set master mode to cause start condition to be sent
    }

The three lines labeled with {116} are new. The wait will very rarely be required and is only very short when it does occur. There is no interrupt available to 'automate' this but this solution seems to be fine.



Regards

Mark
« Last Edit: December 30, 2009, 06:01:29 PM by mark »