Author Topic: M5223X Service Pack 7 available  (Read 4845 times)

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3191
    • View Profile
    • uTasker
M5223X Service Pack 7 available
« on: May 04, 2008, 09:14:56 PM »
Hi Coldfire fans!!

Please note that a new service pack (SP7) is now available for this project. See the service pack page for the link to it and SP release notes - http://www.utasker.com/software/softwareV1.3.html

This service pack is very hardware related. The chips have great peripherals and has fast become a favourite for industrial projects. Such projects start using the uTasker primarily due to its Ethernet support and specifically it TCP/IP stack but don't stop there. The projects' main tasks are usually to do with control and so the Ethernet connection is not the only peripheral which is required. This service pack adds more HW interface support as required by such projects so as to enable faster and more efficient realisation of greater parts of real-world project.

Here's a quick list of new features:
  • ST SPI FLASH driver
  • ADC interface (with interrupt based trigger level, zero crossing and SYNC support)
  • Practical PIT interrupt interface for HW delays
  • Powerful DMA Timer interrupt interface allowing flexible delays, frequency generation and capture applications
  • Improved peripheral power management support built in to all drivers
  • FTP script examples and DEL *.* option
  • M5221X and M5222X project support
  • _SETBITS and _CLEARBITS macros for improved port efficiency
  • More flexible PLL configuration
  • Simulation support for all new features

I have to admit that the ADC interface was quite a task due to the fleixibility and rich features offered by the chip. The resulting interface allows most of the ADC modules capabilities to be simply used without need for detailed knowledge of the internal workings - for example, the power management is optimised to enable only parts of the module which are used; ports are automatically configured as ADC or SYNC inputs based on the user's requirement and sampling scans are optimised to incorporate only the necessary sequences based on present ADC configuration.

It will be necessary to add documentation concerning the new interfaces but they can be simply tested as follows using the examples in application.c.

PIT: enable HW support using SUPPORT_PIT1 in app_hw_m5223x.h and the demo TEST_PIT in application.c. This will show the module being set up for a few different periods and handling each via an interrupt.

DMA Timers: enable HW support using SUPPORT_DMA_TIMER in app_hw_m5223x.h and the demo TEST_DMA_TIMER in application.c. This will show the module being set up for a few different periods and handling each via an interrupt. Part way through the test  a second DMA Timer is configured to generate a frequency, which then apears on its related TOUT pin.

ADC: enable HW support using SUPPORT_ADC in app_hw_m5223x.h and the demo TEST_ADC in application.c. This will show the module being configured to generate interrupts when the input signal leaves a defined voltage range. A second input will be configired with an offset and interrupt on zero-crossing. The code can be changed (using examples there) to test differential inputs and the use of the SYNC to activate a conversion scan with interrupt on completion.

The simulator allows all these to be tested without hardware. In the case of the ADC, the voltage on the input can be displayed by positioning the mouse over the port. By clicking on the port, the input voltage will be increase in steps. By clicking on the port with the SHIFT key held, the voltage will be decreased. This allows the trigger levels to be easily tested and also a conversion to be activated by a rising edge on the appropriate SYNC input.

Note that the (previously existing) edge port module interface code has been made conditional on the define SUPPORT_EPORT (see app_hw_m5223x.h) and will need to be activated if your project is already using it!

Good luck with the SP7. I believe that the new interface support will enable useful savings in a variety of practical projects - if you discover any difficulties or restrictions in the new interfaces please report them here.

Regards

Mark


« Last Edit: May 04, 2008, 10:06:35 PM by mark »

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3191
    • View Profile
    • uTasker
Re: M5223X Service Pack 7 available
« Reply #1 on: May 21, 2008, 11:15:20 PM »
Hi

Here are a couple of notes about SP7 compatibility and known patches (monitor for latest fixes!!).

  • SP7 delivers a config file called config_ref_m5223X_sp7.h (in \uTaskerV1.3.0_M5223X\Applications\uTaskerV1.3). It leaves the oiginal config.h, from the V1.3. If you are installing V1.3 + SP7 simply delete config.h and rename config_ref_m5223X_sp7.h to config.h and everything will work as the release was tested.
  • If you are adding SP7 to update your own project it will thus not disturb your config.h. There will however possibly be 2 changes needed so that the project compiler without errors:

Compile errors using original config.h with SP7:
  • 'DynamicCnt' : Is not an Element of 'stHTTP'
  • POINTER_USER_NAME' and 'POINTER_USER_PASS' not declared

To remove these compiler errors the following changes can be made to config.h:

#define POINTER_USER_NAME parameters->cUserName  // define where the user name and password is taken from
#define POINTER_USER_PASS parameters->cUserPass


// in the USE_HTTP block
#define HTTP_DYNAMIC_CONTENT   // activate support of dynamic content generation
#ifdef HTTP_DYNAMIC_CONTENT
    #define HTTP_USER_DETAILS      // enable the application to manage details belongin to a particalar connection
#endif


In fact the second one should not really need to be used but there is a dependency which is not absolutely correct. This will be impoved by the next SP.



When using CW7.0 it has been found that some project settings can get lost when converting (see: http://www.utasker.com/forum/index.php?topic=277.0) and also sometimes a library (which is not actually needed) is not found. If you do get this error is it safe to simply delete the library from the project.

Note too that the qualitity of the CW7.0 version is presently a bit suspect. It has some library issues of its own (reference: http://forums.freescale.com/freescale/board/message?board.id=CWCFCOMM&thread.id=2006) and it sounds as though the optimisation has some errors too (see: http://forums.freescale.com/freescale/board/message?board.id=CFCOMM&thread.id=4528). CW6.3 and CW6.4 are recommended if you do run ninto any of these difficulties!)


IRQs (Edge ports) in SP7: There are two corrections needed for these to operate correctly.
The first is on the target - in SP7 we get more environmentally concious and disable clocking of most peripherals as default, meaning that the peripherals have to be explicitely powered when used. The edge port interface forgets to do this and so the interrupts don't arrive as expected.
Correction - in m5223c.x in the routine fnConfigureInterrupt() add the line POWER_UP(POWER_EPORT):
    case PORT_INTERRUPT:                                                 // 80 pin version has IRQ 1..7
        {
            unsigned char ucIRQ_bit = (((INTERRUPT_SETUP *)ptrSettings)->int_port_bit);
            unsigned short usMask, usValue;
            unsigned short *EPPAR = EPPAR0_ADR;                          // assume eport 0
            POWER_UP(POWER_EPORT);                                       // {55} apply power to edge port module
...


The second concerns only the simulator and edge ports IRQ8..IRQ15, which sometimes don't interrupt due to an error in the simulator. This can be corrected in M5223XSim.c in the routine fnIRQ_int()

        if ((IC_IMRL_1 & MASK_ALL_INT) || (IC_IMRH_1 & ((IRQ8_PIF_INT_H << irq_vector)))) { // {31}

instead of
        if ((IC_IMRL_1 & MASK_ALL_INT) || (IC_IMRH_1 & ((IRQ8_PIF_INT_H << (irq_vector - 1))))) {
(irq_vector -1) should be irq_vector


Boot loader:
To use the boot loader with SP7 a define needs to be added to the boot loader config.h as detailed in the following thread:
http://www.utasker.com/forum/index.php?topic=295.msg1193#msg1193

RTC: When running the RTC from the main crystal oscillator, and using PLL (not 32kHz crystal as possible with some devices) there is a frequency correction here: http://www.utasker.com/forum/index.php?topic=550.0


Regards

Mark

« Last Edit: March 25, 2009, 02:33:46 PM by mark »