┬ÁTasker Forum

┬ÁTasker Forum => NXPTM M522XX, KINETIS and i.MX RT => Topic started by: mark on March 14, 2011, 11:32:48 PM

Title: M522XX V2 Project Code
Post by: mark on March 14, 2011, 11:32:48 PM
Hi All

Below are links to the V1.4 versions of the M522XX package. It is recommended to use the latest version; older revisions are available as reference or in case of the need to revert back to an older package.

Please use this thread for feedback about any problems or patches.



uTaskerV1.4.0 M522XX - 12.08.2009 - http://www.uTasker.com/software/V1.4/uTaskerM522XX_V1.4-0.zip

Original V1.4 release.

uTaskerV1.4.1 M522XX - 11.10.2009 - http://www.uTasker.com/software/V1.4/uTaskerM522XX_V1.4-1.zip

See file headers for changes - no additional information here.

uTaskerV1.4.2 M522XX - 03.01.2010 - http://www.uTasker.com/software/V1.4/uTaskerM522XX_V1.4-2.zip

- uTaskerCombine V1.1 in \Tools allows Intel Hex file output beyond 64k size
- IRQ7 test adapted to avoid message queues
- random ID added to DNS to avoid problems with servers rejecting repeated IDs
- New permanent ARP entry option
- New application project "serial loader"
- Optionally add HTTP plain text header information - define HTTP_HEADER_CONTENT_INFO
- optional USE_PARAMETER_AREA support (as simple alternative to USE_PARAMETER_BLOCK)
- utFAT V1.0 SD card support added (integrated in FTP, HTTP servers plus DOS-like interface)
Note that SDCARD_SUPPORT is enabled by default and GLCD is disabled (M52259 EVB selected) - the heap size has been increased to enable utFAT together with other services

uTaskerV1.4.3 M522XX - 14.03.2011 - http://www.uTasker.com/software/V1.4/uTaskerM522XX_V1.4-3.zip
- Various improvements and patches (see headers in files for details)
- Kirin3 Tower Kit support
- PWM interface support
- M5214, M5216, M5280, M5281, M5282, M5207 and M5208 support
- Managed file support
- IPv6 basic included
- USB Mass Storage capability together with SD-card
- GLCDLIB extended with Bitmap windowing support
- Task Performance monitor added (MONITOR_PERFORMANCE) - request via command line menu interface
- VS 6 and VS 2010 projects
- CodeWarrior 10.1 projects

Note that this package uses a new Eclipse-compatible structure due to the fact that CodeWarrior is based on this. The following is a quick-start guide to importing the project into CW10.1:

The first time that Codewarrior is started it requires a workspace to be defined. The workspace can be located anywhere and the project will later be imported into the workspace.
Once Codewarrior has started, the µTasker project can be imported. This is achieved by selecting the context menu (right mouse click) in the “CodeWarrior Projects” window and commanding “Import…”. In the import dialog the action “General | Existing Projects into Workspace” can be selected and then the root directory set to uTaskerV1.4 project directory. The import doesn’t need to copy the project to the workspace.
Once the import has been executed the project is seen as uTaskerV1.4 in the CodeWarrior Project window, with four targets “M52259_INTERNAL_FLASH” and “M52259_INTERNAL_RAM, M522xx_Boot_Flash and serialBoot”.
Ensure that the target board is configured for the processor and board [config.h and processor family setting in the project settings, plus that the linker script file configured for linker use is suitable]
.The project is compiled by clicking on the build button (Ctr + B will start a complete build).
Note that the boot loader projects are contained in the project and selected for building as build targets (this is how Eclipse based environments seem to handle this best).

uTaskerV1.4.4 M522XX - 23.03.2011 http://www.uTasker.com/software/V1.4/uTaskerM522XX_V1.4-4.zip
- uTaskerV1.4 project for IAR (configured for M52259 - can be easily adapted for any V2 type)
- FAT16 support added (define UTFAT16 in config.h). SD cards can be formatted for FAT32 or FAT16 as follows:
"format -16 label_name" or "re-format -16 label_name". Without the -16 FAT32 is formatted.
Support for 512 byte clusters only so intended primarily for small FATs (potentially in internal FLASH) up to 32M
and not generally for large SD card use

Note: when using the V1.4-4 together with CW10.1 please add the following towards the start of M5223X.c:

    #ifdef _CODE_WARRIOR_10
        #define __interrupt__   __declspec(interrupt)

It is adviable to activate the following processor options in the CW10.1 poject (will be set as default in future versions):
-   Register coloring
-   Instruction scheduling
-   Peephole

These can be set in the C-compiler processor options - as reference, a project with 113k code size could be reduced to 84k code size by enabling these, which give about the same code size as the CW7.2 project.

uTaskerV1.4.5 M522XX - 14.05.2011 http://www.uTasker.com/software/V1.4/uTaskerM522XX_V1.4-5.zip
- workaround for CW7.2 optimising error in UART reception
- correction of CAN block address for M5225X family and general CAN speed formular based on used crystal speed added
- CW10.1 project configured with
-   Register coloring
-   Instruction scheduling
-   Peephole
which greatly reduces the generated code size.
- uTaskerConvert.exe V1.6 - "uTaskerConvert.exe uTasker_BM.bin raw.bin -b" can be used to convert an input file in Motorola binary format to raw binary format.
- IAR Serial Loader project added
- uTaskerFileCreate V1.7 updated (see http://www.utasker.com/forum/index.php?topic=1114.msg5330#msg5330)
- New USB boot loader support as shown in the (Kinetis) video http://www.youtube.com/watch?v=H4TYM9jY2-g (M5225x and other USB capable devices)

If using CW7 and M52211_FLASH.lcf please correct the SP setting to ___SP_INIT   = ___SRAM + ___SRAM_SIZE - 4; [rather than + 4 !!]
Warning to M5223X CW users since the M5225X project presently shares the M5223X configuration. Verify that the linker script file M52235EVB_FLASH.lcf is configuring the correct SRAM size - if it sets 64k as used by the M52259, it will not be able to operate so reduce the setting back to 32k {sram    (RWX)  : ORIGIN = 0x20000400, LENGTH = 0x00007C00} {___SRAM_SIZE   = 0x00008000;}
The next version will include M5225X targets to avoid confusion.

uTaskerV1.4.6 M522XX - 30.08.2011 http://www.uTasker.com/software/V1.4/uTaskerM522XX_V1.4-6.zip
- New USB VID/PID for Freescale MSD project
- USB MSD Boot Loader - password software protection added (see http://www.utasker.com/forum/index.php?topic=1434.msg5576#msg5576)
- Correct port TA display in M521X simulator
- UART simulator extended to handle 6 internal UARTs and 4 external ones
- validated version of zero-configuration, including state display in simulator.
- added optional RAM test to application.c [#define RAM_TEST in application.c] - according to http://www.utasker.com/docs/uTasker/uTasker_RAM_test.pdf
- RTC_SETUP adapter for generic time-keeping compatibility with time date setting/display in command line menu. Beware that the interface is not fully compatibel with the previous version and so, when setting alarms and time the months and year need to be set too. See RTC_TEST in application.c for reference. Driver includes in-built time/Gregorian calender support according to: http://www.utasker.com/forum/index.php?topic=1656.0
- Character LCD simulator allows read of character content.
- INDIVIDUAL_BUFFERED_TCP_BUFFER_SIZE allows buffered TCP sockets to define different buffer sizes for each socket. Use extern unsigned short fnDefineTCPBufferSize(USOCKET TCP_socket, unsigned short usBufferSize); to allocate the size to be used by the socket before first use. TCP_BUFFER is used (for compatibility) if no size is set.
- Enabling SUPPORT_FILE_TIME_STAMP (requires SUPPORT_RTC) adds date/time stamps to utFAT file/directory writes.
- _VARIABLE_HTTP_PORT allows the HTTP server to be started with a user-defined port number rather than fixed port 80.
- DNS_SERVER_OWN_ADDRESS adds command to set individual DNS server address, otherwise it follows the default gateway value.
- corrections in utFAT when writing clusters over sector boundaries and deleting clusters on big-endian processors.
- utFAT FAT16 mode corrections.
- ETHERNET_RELEASE_AFTER_EVERY_FRAME options according to http://www.utasker.com/docs/uTasker/uTasker_Ethernet_Reception.pdf
- M52259 targets added to CW7.x uTaskerV1.4 projects
- Display connection IPv4 address on start page of web server
- EXTENDED_UFILESYSTEM support (details follow)

When enabling DNS_SERVER_OWN_ADDRESS, add the following define to debug.c:
    #define DO_SET_DEFAULT_DNS      16                                   // specific IP command to set default DNS IPv4 address

uTaskerV1.4.7 M522XX - 08.10.2011  http://www.uTasker.com/software/V1.4/uTaskerM522XX_V1.4-7.zip

- M5235BCC Ethernet operational, with PHY and IRQ support (configuration in CW7.2 project)
- Control of use of HW random number generation moved from M5223X.h to hw_app_m5223X.h
- Simulation assertions use _EXCEPTION("text indication cause of assertion")
- Counter of number of times the start web side has been served added to the demonstration
- Option (SPECIAL_LCD_DEMO) to stop GLCD demo when an image is posted to the TFT via HTTP
- file system supported in external parallel Flash (M5235BCC example)
- uFileSystem revision 1 including seamless file operation in multiple storage media and multiple devices in each media - generic rework to allow simpler extension with new types as well as device count being set at run-time.
- EXTENDED_UFILESYSTEM extended with UFILESYSTEM_APPEND - see http://www.utasker.com/docs/uTasker/uTaskerFileSystem_3.PDF (version 0.05)
- Optional uFileSystem revision 1 (define STORAGE_REV_1) - see http://www.utasker.com/docs/uTasker/uTaskerFileSystem_Revision1.pdf
- Note that I2C_FILE_SYSTEM has been changed to I2C_EEPROM_FILE_SYSTEM

When using SPI Flash, change internal_flash to default_flash in the spi flash driver files.
If a VS simulation build fails due to ID_TEST_R4 not being found delete the file resource.h in its simulation directory and rebuild.

When working with STORAGE_REV_1 and simulating, add the following to the start of the routine fnGetParsFile:
#ifdef _WINDOWS
    if (iFetchingInternalMemory != 0) {
        uMemcpy(ptrValue, ParLocation, Size);                           

When working with file system exclusively in internal flash the erase routine needs to be put into a loop as follows (the loop was missing):
    ptrSector = (unsigned char *)((CAST_POINTER_ARITHMETIC)ptrSector & ~(FLASH_GRANULARITY - 1)); // set to sector boundary
    do {                                                                 // {150}
        #if !defined _M520X && !defined _M523X
            #ifdef _WINDOWS
        CFMUSTAT |= CBEIF;                                               // no command queued
        if (!(CFMUSTAT & CBEIF)) {
            return 1;                                                    // the command buffers are full - we cannot proceed
            #ifdef _WINDOWS
        fnDeleteFlashSector(fnGetFlashAdd(ptrSector));                   // simulate deletion of single sector
        if ((fnFlashNow(CMD_SECTOR_ERASE, (unsigned long *)((unsigned long)fnGetFlashAdd(ptrSector) & ~0x3), (unsigned long)0)) != 0) { // ensure long word address
            return 1;                                                    // error
        if (Length <= FLASH_GRANULARITY) {                               // check whether entire deletion has completed
        ptrSector += FLASH_GRANULARITY;                                  // advance sector point to next internal flash sector
        Length -= FLASH_GRANULARITY;
    } while (1);

At the start of the function
extern int fnEraseFlashSector(unsigned char *ptrSector, MAX_FILE_LENGTH Length)
there is an #endif followed by a comma.
GCC doesn't like this so the (unnecessary) comma should be deleted...

    #ifdef MANAGED_FILES
    MAX_FILE_LENGTH OriginalLength = Length;

To use the new RTC interface in the command line menu (#define SUPPORT_RTC) the following prototype and defines need to be added to application.h:

extern unsigned char fnSetShowTime(int iSetDisplay, CHAR *ptrInput);
    #define DISPLAY_RTC_TIME_DATE   0
    #define SET_RTC_TIME            1

uTaskerV1.4.8 M522XX - 03.01.2012 http://www.uTasker.com/software/V1.4/uTaskerM522XX_V1.4-8.zip
- Correct internal flash delete in revised flash handling (add sector loop) and return storage media page size when deleting with managed files support
- Allow memory-mapped read from unspecified storage media so that files in SRAM (for example) can be accessed without explicitly declaring the area
- SINGLE_FILE_SIZE is no longer used. FILE_GRANULARITY is now used exclusively in all uFileSystem components (the meaning is the same)
- Allow scrolling up and down to previous commands in command line and editing the command with option PREVIOUS_COMMAND_BUFFERS as number of buffers
- Some corrections to extended file system now verified for over 1'000 files and FTP directory listings
- Dual FlexCAN driver including interraction with CAN systems from uTasker simulator using KOMODO CAN DUO (see video http://www.youtube.com/watch?v=Ha8cv_XEvco&feature=youtu.be )
- FTP client according to the FTP client user's guide: http://www.utasker.com/docs/uTasker/uTaskerFTP_client.pdf (see video http://www.youtube.com/watch?v=sZOCFLDfGTk&feature=youtu.be )

uTaskerV1.4.9 M522XX - 08.01.2012 http://www.uTasker.com/software/V1.4/uTaskerM522XX_V1.4-9.zip
- PHY check added for devices with internal EPHY; MDIO clock is not stopped when EPHY available since it hold back EPHY interrupt generation.
- EPHY debug interface added to command line interface as an option in debug.c - see DEVELOP_PHY_CONTROL
- Start web page for smallest web content reference reduced in size to fit into since Flash sector

When using CAN the clock setting may need to be corrected as follows in M5223x.c in the new routine fnOptimalCAN_clock():
ulBestPrescaler |= ((iBestTimeQuanta << 19) || (iBestTimeQuanta));
should be
ulBestPrescaler |= ((iBestTimeQuanta << 19) | (iBestTimeQuanta)); {the logical OR should be replaced by arithmetical OR}

uTaskerV1.4.10 M522XX - 13.02.2012 http://www.uTasker.com/software/V1.4/uTaskerM522XX_V1.4-10.zip
- HID mouse added to USB device support - define USE_USB_HID_MOUSE enables in config.h
- Boot loading from SD card added as option to serial loader project
- IAR projects added to serial loader and "bare-minimum" boot loader
- Additional queue protection added to allow nested writes and nested reads from same queue in interrupts

In the boot loader config.h file there is a new condition
#if !defined _ASSEMBLER_CONFIG                                           // {20}
which was added for IAR use.
This should be moved down to just after the line
#define KIRIN3                                                           // M5225X family - otherwise remove!
when building the boot loader for KIRIN3 devices (M5225x) so that this define is recognised.

It has been noticed that the routine to delete/write Flash can crash when executed using the uTasker simulator and VisualStudio 2010. This part of code is running from RAM, which seems to cause VS 2010 a difficulty. The following modification will allow the simulator to run the code directly (this also allows stepping the code at source level rather than disassembly only), which then works fine with VS 2010:

In fnFlashNow() in M5223X.c
    if (!fnRAM_code) {                                                   // the first time this is used it will load the program to SRAM
        uMemcpy(ulProgSpace, (unsigned char*)fnFlashRoutine, PROG_SIZE);
        fnRAM_code = (void(*)(void))ulProgSpace;
#ifdef _WINDOWS
        fnRAM_code = fnFlashRoutine;                                     // allow simulator to work with original code rather than RAM based code

uTaskerV1.4.11 M522XX - 02.03.2012 http://www.uTasker.com/software/V1.4/uTaskerM522XX_V1.4-11.zip
- Advanced IPv6 support with link-local and global IPv6 addresses. TCP based services (such as HTTP and FTP) are operational on link-local IPv6 address and global IPv6 address as well as IPv4 (dual-stack).
- Global IPv6 address can be optionally tunnelled in 6in4 (tunnelling IP address is configurable) when native IPv6 is not possible.
- Configurable 6in4 relay agent to expose multiple IPv6 devices behind simple IPv4 routers.
- Start web page shows IPv4 or IPv6 source address depending on connection.
- Access to SD card (utFAT) controllable individually of HTTP and FTP and root directories can be changes during operation.
- SD card visualisation in simulator (preliminary)
- Optional polling of SD card to detect removal during operation

The following correction allows TCP resets to be correctly returned when a connection is refused:

In the routine fnTCP_send_reset() in tcp.c
    if (iIPv6 != 0) {                                                    // if connecting over IPv6
        uMemcpy(ptr_TCP->ucRemoteIP, ((IP_PACKET_V6 *)received_ip_packet)->source_IP_address, IPV6_LENGTH); // enter the peer's IPv6 address on connection attempt {45}
        ptr_TCP->ucTCPInternalFlags |= TCP_OVER_IPV6;                    // flag that the socket is operating over IPv6
    else {
        uMemcpy(ptr_TCP->ucRemoteIP, received_ip_packet->source_IP_address, IPV4_LENGTH); // {45}
        ptr_TCP->ucTCPInternalFlags &= ~TCP_OVER_IPV6;

Changes marked by {45}

When working with managed files and multiple storage media (eg. internal Flash and external SPI Flash) the following correction needs to be made in fnEraseFlashSector():

Original -
        if (Length <= AccessDetails.BlockLength) {                       // if completed
        #ifdef MANAGED_FILES
            if (OriginalLength == 0) {                                   // if a single page erase was called, return the page size of the storage area
               return AccessDetails.BlockLength;                        // return the page size that was deleted in the storage media

        if (Length <= AccessDetails.BlockLength) {                       // if completed
        #ifdef MANAGED_FILES
            if (OriginalLength == 0) {                                   // if a single page erase was called, return the page size of the storage area
               return AccessDetails.BlockLength;                        // return the page size that was deleted in the storage media
        #endif                                                           // <---- break must always be true

When working with the Ethernet receiver in USE_MULTIPLE_BUFFERS mode please see the following for a correction to protect against possible linear buffer overflow:

Please note that the SW packages are protected by the corresponding project password.
To register and receive the password, simple fill out the form: http://www.utasker.com/Licensing/request.html
Don't be afraid - the project is free and supported for everyone; just for commerical use a small fee for premium
support is requested (donation after making their first million profit also welcomed..;-)
Title: Re: M522XX V2 Project Code
Post by: neil on March 22, 2011, 10:02:33 AM
Hi Mark,
 I have the version before this, and have a few questions.

1. Is there any core modifications to utasker?
2. What is M5214 .. I searched the web and got many different results.
3. what is managed file support?
4. what exactly is USB mass storage?

Title: Re: M522XX V2 Project Code
Post by: mark on March 22, 2011, 02:16:55 PM
Hi Neil

1) There are a few bug fixes - eg.:
   22.10.2010 Correct starting a new timer just before an existing fires {6}
   17.01.2011 Ensure stTimer is zeroed at reset                          {7}

and minor additional features - eg: a new, optional task monitoring feature.

It is best to read through the headers in the uTasker files and compare with your version to see what is new or patched - then you can decide whether they are relevant to your use or not.

2) http://www.freescale.com/webapp/sps/site/prod_summary.jsp?tid=mcHp&code=MCF521X The M5214 and M5216 are like the M5213 (CAN) with additional SDRAM controller.

3) Managed file support uses the mass storage task to perform functions as backgorund activity and can protect files being used from other callers (eg. stopping them modifying a file in use).
The FTP command "del *.*" used this new support as follows [when MANAGED_FTP_DELETES is also enabled] (it is about the only place that it is used in the demo project code but can be used by application code when useful) - originally this command would cause the FTP server to completely delete the content of the uFileSystem in one go. This could take several seconds and during this time the system would wait until the call returned.
When managed file support is enabled the delete is passed to the mass storage task which will handle the delete operation as a background process. The system will otherwise be able to continue operating and the FTP module is informed when the operation has completed (in case of large SPI FLASH this could be many seconds later), and the FTP module then closes the FTP data connection and informs the client that the command was successful.
If you search for MANAGED_FTP_DELETES the method can be seen. [In fact also single file deletes are handled using this method and so background deleting has much less effect on general system operation].

The following example shows this in operation:

                  MANAGED_MEMORY_AREA_BLOCK memory_area;
                  memory_area.ptrStart = uOpenFile((CHAR*)(ucIp_Data + 5));// start address of the area to be deleted
                  memory_area.size = uGetFileLength(memory_area.ptrStart); // size of area to be deleted
                  memory_area.period = 0;                              // page delete once every scheduling pass
                  memory_area.ucParameters = (AUTO_CLOSE | AUTO_DELETE); // on termination automatically close the file
                  memory_area.fileOperationCallback = fnDelete_terminated; // callback on completion
                  if (uOpenManagedFile(&memory_area, OWN_TASK, (MANAGED_MEMORY_AREA | MANAGED_DELETE)) < 0) { // open the file which will be automatically deleted and closed
                        return (fnSendFTP(MSG_FTP_DENIED));
                  return APP_ACCEPT;                                   // return OK after the delete has been successful

The struct memory_area is filled and passed to uOpenManagedFile(). The struct contains details about the memory area to be deleted, gives a call-back to be called when the deletion has terminated (so that the caller knows that it has completed and can continue with further operations). The entry memory_area.period allows control of the mass storage task performance. With 0 it means that the task will poll as fast as it can when performing the operation - otherwise it can, for example, be controlled to operate just once every 10ms - this may mean that the delete process takes a bit longer but there is less loading due to the mass storage task's operation.

This deletion case is the one that has been used most up to now since it is what otherwise blocks the system a bit - other mechanisms are also contained in the new support but haven't been used much yet. Possibly further expansions will prove useful in particular cases.

4) USB-MSD is the USB Mass Storage Device class operation. That means that a PC host sees the device as an external hard disk and can read and write it (mainly SD card connected to the processor). A user's guide will be made available shortly explaining its implementation and use. To activate it in the present version (required USB and SD card support) the define MJBC_DEVELOP_MASS_STORAGE can be activated in usb_application.c. This causes the USB application interface to behave as MSD rather than CDC class.


Title: Re: M522XX V2 Project Code
Post by: neil on March 22, 2011, 03:06:46 PM
Hi Mark,
  Thanks for the reply.

1. As my project is up and running, I dont want to copy across all and then have to go through the config.h for example and change my settings. Can I use my same project files, and only copy across the must files?

2. If so what is the list of these?

3. Do I need to update the bootrom project I am using codewarrior 7.2?

4. Do the virtual com driver for the USB work on Windows 7,Vista,XP 32 & 64 bit?

Title: Re: M522XX V2 Project Code
Post by: mark on March 22, 2011, 04:55:18 PM

1) + 2) It should be possible to copy all framework files (that is, files outside of the application directory) and use them as they are. New features are always activated by new defines (without the new defines you will have the original feature set and just the new patches).

The only exceptiosn are:
a) there may be a couple of routines that have been renamed to better reflect their usage. These will appear as linker errors - search for them in the reference application and then make the same rename in any of your own code.
b) there may be a couple of new defines that the project expects - eg. TICK_INTERRUPT() If there is acompiler (or linker) error due to something like this not being defined search for it in the reference project and copy to one of your headers. (Often then can be set a dummy define [that is, with no value] so that they don't actually change anything.

3) There is no need to update the boot loader project. There may however be small improvements in the boot-loader main routine or HW files so it is best to check their headers for new notices (there are very few files to check).

4) The virtual com driver hasn't been updated and so will probably not support all OSs. I think that you managed to adapt a version from another source previously - I have also an adapted version but haven't completed testing yet so didn't update anything at the moment.



Title: Re: M522XX V2 Project Code
Post by: neil on March 23, 2011, 12:22:04 PM
Hi Mark,
  The USB Mass Storage Device, does this use Windows own driver or will there be same problems with the CDC class?

Title: Re: M522XX V2 Project Code
Post by: mark on March 23, 2011, 02:06:07 PM

The advantage of MSD is that there is no need to supply a driver for it. All PC operating systems have their own (compatible) driver that is automatically used when an MSD compatible device is detected. On a Windows PC it is called usbstor.sys.

Note that you will however need to use a different PID to the CDC project.


Title: Re: M522XX V2 Project Code
Post by: neil on March 23, 2011, 02:26:34 PM
Hi Mark,
  What PID should I use?

Looking at the fnComitt_UART() function, is this only used in in demo , as I use the serial port in my own project.

Title: Re: M522XX V2 Project Code
Post by: mark on March 23, 2011, 06:37:42 PM

For testing the PID used is not really important as long as the VID/PID doesn't collide with any other USB device that is in use or has been used (matched for a driver). For products a VID/PID pair is required as discussed in section 4.1 in the USB User's Guide: http://www.utasker.com/docs/uTasker/USB_User_Guide.PDF

fnComitt_UART() is used in the CDC example so that the PC can control the UART setting of the debug interface. This is because the CDC demonstration allows  USB<->UART converter operation. The file usb_application.c (which also contains the USB-MSD interface when CDC is not selected) is an application file and so can be changed as required. Simply remove the fnCommitt_UART() if not required.


Title: Re: M522XX V2 Project Code
Post by: ssinfod on March 07, 2016, 08:22:22 PM

I'm trying to build and run "uTaskerM522XX_V1.4-11.zip" on the M52233DEMO board. I'm using CodeWarrior 10.5 Special Edition.

I have 3 questions:

Here is what I have done so far but I have compilations errors:

1) Downloaded "uTaskerM522XX_V1.4-11.zip" and unzipped it to "C:\Users\phd\workspace\uTaskerV1-4"
2) Then, I Imported the project in CodeWarrior 10.5. I selected the folder "C:\Users\phd\workspace\uTaskerV1-4" for the importation.
Note: In the importation I have the following warning. (See attached picture: "CW10.5_Warning.png")
References to the ${workspace_loc:{<resource>} macro were found in the project settings. Using this macro could cause unexpected errors when the resource is not open or available in the workspace. Using the ${ProjDirPath} macro is preferable. ...

3) Then I perform a "Build All" and I have 80 errors related to "GLCD.c" in "/uTaskerV1-4/uTasker/uGLCDLIB"

What is wrong with GLCD ? (I mean this is the out of the box configuration ?)

I also see the following folder "C:\Users\phd\workspace\uTaskerV1-4\Applications\uTaskerV1.4\M522XXCodeWarrior_CW10"
Do you have to import from this folder instead of "C:\Users\phd\workspace\uTaskerV1-4\" ?
What do I have to do with ".lcf" file in this folder "C:\Users\phd\workspace\uTaskerV1-4\Applications\uTaskerV1.4\M522XXCodeWarrior_CW10\Project_Settings" ?

I also want to build this project for the M52233DEMO board.
What do I have to change to build the project for the M52233DEMO ?
This is what I tried:
1) "Project Properties", "C/C++ Build", "Settings", "Coldfire CPU", and set "Processor Family (-proc)" to 52233 ?
2) Also I verified the define in "Applications/uTaskerV1.4/config.h". (around line 112)
        //#define M52235EVB                                                // EVB Board for M52235
        #define M52233DEMO                                               // DEMO Board for M52233

Do you have to change something else ?
What target should I use for the build ?  (My choices are: MCF52259_Internal_RAM, MCF52259_Internal_Flash, MCF522XX_Boot_Flash, SerialBoot)

It seems the uTasker project doesn't have the EWL library.
I would like to add it to the project so I have the C standard library with stdio.h (printf, scanf) and also stdint.h, stdbool.h and math.h (ex: cos/sin).

Can you tell me what to change to enable the EWL library in CodeWarrior 10.5 ?

Thanks for your time,
Title: Re: M522XX V2 Project Code
Post by: mark on March 08, 2016, 01:03:44 AM

1. It is correct to import form the top level directory. The directory \Applications\uTaskerV1.4\M522XXCodeWarrior_CW10 is used as an output directory for the binary files built with this IDE.
I believe that there are import warnings but they shoudln't cause any problems.
When I test the project (out-of-the-box) with VisualStudio and GCC there are no problems so whatever is the issue with GLCD.c it must have something to do with CW10.5 - this file is however used by the configuration since it is for the M52259 EVB with TFT active. You could remove SUPPORT_GLCD so that the GLCD is not used to check that it is the only problem. Certainly also try a clean/rebuild to be sure that the initial build is complete.
The linker script files in \Applications\uTaskerV1.4\M522XXCodeWarrior_CW10\Project_Settings can be selected to match the target being used.

2. The settings fo rthe M52233 are correct. You can use MCF52259_Internal_Flash for a standalone application that runs in Flash and select the linker script file (from the folder above) to suit the memory size invoved. When the other settinsg have been changed the "MCF52259" has been modified to suit another target  you could also make a copy of this setup and rename it to suit the one your require so that it would then be possible to switch between the two.

3. The uTasker project avoids libraries as far as possible but you can add additional libraries in the linker settings of the project. There is either a list of librares that can be used or else you may have to manually add its path names - since I haven't used CW10.5 for Coldfire for a number of years I don't have an installation to quickly check on at the moment but you should also find such details in its help menu..