Topics

211

NXP^TM M522XX, KINETIS and i.MX RT / M5221X RTC

« on: June 07, 2008, 04:36:53 PM »

Hi All

A feature of the M5221X devices is that they have a battery backup for the RTC (can use a 32kHz crystal) and the internal SRAM. This means that SRAM data content and also the time (date) can be retained during power down.

The documentation about the use of these and their characteristics are not that clear so I though it would be interesting to do some tests. The support is being added to the uTasker project to enable simple configuration where required.

1. It was possible to activate the 32kHz RTC oscillator. This requires the external 32kHz crystal to be connected to the pins normally used for UART0 RX/TX, where the secondary functions are RTC_EXTAL and  RTC_XTAL respectively.
This seems rather unfortunate since there are no alternative pins for the UART0 RX/TX lines, although the corresponding RTS/CTS lines are not affected. UART0 doesn't no seem to be usable of the external RTC crystal is used.
Furthermore it was found that it was not necessary to program the configuration of the pins in the PUAPAR register, but only necessary to configure the source of the oscillator in MCF_CLOCK_RTCCR. Reading PUAPAR back doesn't reflect this configuration so it must be controlled parallel to this.

2. The M52210DEMO board was used to test current consumption. This has a large "Super"Capacitor of 1.5F on the board which is charge via a resistor from the 5V supply when the board is powered.
It takes about 40 minutes for the empty capacitor to be charged to about 3.3V since the current is limited via an equivalent resistance of about 280R.
When the RTC crystal is not configured, the current consumption in power down state (Vstby) was measured to be about 2uA.
When the RTC crystal was configured it remained in operation during the power down state, drawing about 15uA current.

3. It has been found that the RTC registers can be viewed and modified using the register viewer with the CodeWarrior debugger but not in the memory area when they exist (eg. 0x400003c0). The reason for this is presently not known!

4. At the time of writing the actual use of the RTC has not been successful since it has not yet been possible to starts its counting operation. This difficulty has also been experienced by other users and it is hoped that the cause for this can be identified shortly: http://forums.freescale.com/freescale/board/message?board.id=CWCFCOMM&message.id=1871&jump=true#M1871

Regards

Mark

Update: the correct operation was achieved, whereby difficulties were mainly due to the register access RTCGOCL which must be as long access, although its contents are onle 16 bits wide. 16 bit writes are not accepted. (full details can be found in the linked thread).

Further information concerning the current consumption of Vbatt in operating and standby states can be found here: http://forums.freescale.com/freescale/board/message?board.id=CFCOMM&message.id=6407&query.id=118275#M6407

212

µTasker general / uTasker and Vista

« on: May 30, 2008, 04:36:28 PM »

Hi All

Since laptops nowadays are no longer costing a year's salary (now only a few months' salary;-) ) I decided that it was time to get a new one exclusively for testing the latest releases of all software used by the uTasker project.

This means mainly together with Vista, VisualStudio2008 etc.

I will certainly continue most work using my trusted XP laptop with VS6.0 and all sorts of out-dated and not-at-all trendy programs (as long as not too many more keys fall off the keyboard....it is looking rather old recently) until I am sure that it is really safe to switch at some time in the future.

I have started testing and already have encountered first problems. I am sure that others have similar issues, which have been solved or worked around - and that, with time, more and more people will be upgrading - so the problem list (and hopefully some answers) may prove useful.

So - here's my list - any comments, additions or solutions are very welcome:

1. VisualStudio2008 (VS9.0 Express Edition) + WireShark 1.0.0. Installations much improved in comparison with previous versions - WireShark automatically installs WinPCap.
uTasker V1.3 + SP7 for Coldfire compiled (using SP7 config.h) with no errors.
Simulator runs and simulated device responds correctly to FTP, HTTP etc. from another PC on the network.
[I just noticed that WireShark is compiled using VS6.0!!]

Problem: Pinging of simulated device from same PC very unreliable - sometimes an answer - mostly none. No FTP / HTTP connection possible from own PC???

Solution: IPV4 offloading setting in the network adapter - see the following for full details and adjustment:
http://www.utasker.com/forum/index.php?topic=180.0

2. From DOS windows arp - a shows the all known entries.

Problem: arp -d returns an error "error deleting the ARP-entry: 87"


3. From DOS windows telnet 192.168.0.3

Problem: telnet 192.168.0.3 Vista doesn't recognise the Telnet command. This must mean that Telnet is not installed as standard. Does anyone know how to get around this?
Solution: In "system control", chose "Programs and Functions". Then click on the link "Activate/Deactivate Windows functions" [in German "Windows-Funktionen ein- oder  ausschalten" - hope the text is more or less correct on a English Vista system]. Then activate Telnet-client and OK. The missing Telnet client program will be installed.


4. HyperTerminal

Well, I know that HyperTerminal as a program was quite a disaster, but I am surprised to learn that it has been completely removed from Vista. Not that I wanted to use it seriously, but TeraTerm (a great freeware program which I have been using for a number of years) has a restriction of only COM1..COM4. With todays USB-RS232 converters you often get COM ports well outside of that range and so I have installed PuTTy for use when TeraTerm doesn't fit the bill.


Regards

Mark

213

NXP^TM M522XX, KINETIS and i.MX RT / _ALIGN_HEAP_4 for optimised memory access speed

« on: May 23, 2008, 11:43:55 PM »

Hi All

Some processors can not access short and long words when they are not aligned on the correct boundaries (eg. 0x0, 0x4 for long word and 0x0, 0x2 for short word). For this reason uMalloc() always returns memory on a long word boundary so that all structs will be aligned and so not cause possible access violations. These processors contain the define _ALIGN_HEAP_4 in their hardware header file.

The Coldfire can access words on odd boundaries and so doesn't 'need' this. However such accesses are not as efficient as natural boundary accesses. For example, to access a long word from an odd boundary it will be necessary to read twice (from the natural boundary below to get the first part, and from the natural boundary above to get the rest). This is quite complicated but is solved in the hardware so that it is not noticed by the user. It means that structs can be packed on each other without ever needing to leave any space. It also means that, although some RAM can be optimised, accesses are not always as fast as they could be.

By putting the define _ALIGN_HEAP_4 into app_hw_m5223x.h it will force uMalloc() to also always return long word aligned memory. This will ensure that all accesses are optimally fast, even if the amount of heap memory required will increase slightly.

You may like to give it a try in your project!!

Note that there are various other hardware requirements for aligning memory. Sometimes this is on a larger boundard (8, 16, 32 etc.) as required by some peripherals. To achieve this specifically the project contains the alternative call uMallocAlign() - this can be passed a paremeter to inform of the required boundary. An example can be found in M5223X.c:
ptrBuffer = uMallocAlign((MAX_MALLOC)(ucMultiBuf*256*NUMBER_OF_RX_BUFFERS_IN_ETHERNET_DEVICE), 16);

Here a buffer for use by the Ethernet controller must have a starting address aligned to a 16 byte boundary.

Regards

Mark

214

NXP^TM M522XX, KINETIS and i.MX RT / 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

215

Luminary Micro ^TM LM3SXXXX / New Luminary devices - USB Host/OTG, ROM and uDMA controller

« on: May 02, 2008, 11:53:29 PM »

Hi All

Luminary is moving fast - another 30 devices are included in the newest line up, including new USB (OTG, Host) types.

New in these chips is a uDMA controller enabling memory-peripheral DMA transfers.

In addition they have ROM containing the boot loader (rather than being pre-programmed in FLASH) plus a set of driver library functions built in.

This pace of new chips and peripherals is quite mind-boggling!!

http://www.luminarymicro.com

Regards

Mark

216

NXP^TM M522XX, KINETIS and i.MX RT / M522XX device overview

« on: April 27, 2008, 10:39:41 PM »

Hi All

The uTasker project is being expanded to run on more of the single-chip V2 devices.
This covers the M521X, M521XX (Basic MCU), M5221X (USB-OTG), M5222X (USB-OTG), M5223X (Ethernet) and Kirin 3 M5225X.

In an attempt to get a side-by-side comparison of these devices I have created the following. It may serve as a guide for choosing the appropriate part for a specific project.
I can't guaranty all details since there are some contradictions in the official documentation but it is based on most recent knowledge and experience. Standard peripherals which are present on all devices are not mentioned in more details (eg. all have 2 x Periodic Interrupt timers, 4 DMA timers, 12-bit ADC etc.)

Regards

Mark


The uTasker project specifically supports the following devices:        [rough budgetary 1000 price - a little package dependent]

_M521X family (basic MCU with CAN)

• _M5211 128k FLASH/16k SRAM 66/80MHz 64LQFP/QFN, 81 MAPBGA                     [$5.40]
• _M5212 256k FLASH/32k SRAM 66/80MHz 64LQFP, 81 MAPBGA                         [$6.80]
• _M5213 256k FLASH/32k SRAM 66/80MHz 81 MAPBGA,100LQFP                         [$8.00]

_M521XX family (basic MCU)

• _M52100 64k FLASH/16k SRAM 66/80MHz 64LQFP/QFN, 81 MAPBGA                     [$4.40]
• _M52110 128k FLASH/16k SRAM 66/80MHz 64LQFP/QFN, 81 MAPBGA,100LQFP            [$5.50]

_M5221X family (USB-OTG)

• _M52210 64k FLASH/16k SRAM 66/80MHz 64LQFP/QFN, 81 MAPBGA                     [$5.00]
• _M52211 128k FLASH/16k SRAM 66/80MHz 64LQFP/QFN, 81 MAPBGA,100LQFP            [$6.50]
• _M52212 64k FLASH/8k SRAM 50MHz 64LQFP                                        [$3.50]
• _M52213 128k FLASH/8k SRAM 50MHz 64LQFP                                       [$4.50]

_M5222X family (USB-OTG)

• _M52221 128k FLASH/16k SRAM 66/80MHz 64LQFP, 81 MAPBGA                        [$6.00]
• _M52223 256k FLASH/32k SRAM 66/80MHz 100LQFP, 81 MAPBGA                       [$7.50]

_M5223X family (Ethernet)

• _M52230 128k FLASH/32k SRAM 60MHz 80LQFP/112LQFP                              [$8.60]
• _M52231 128k FLASH/32k SRAM 60MHz 80LQFP/112LQFP                              [$9.30]
• _M52232 128k FLASH/32k SRAM 50MHz 80LQFP                                      [$5.70]
• _M52233 256k FLASH/32k SRAM 60MHz 80LQFP/112LQFP                              [$9.30]
• _M52234 256k FLASH/32k SRAM 60MHz 112LQFP/121 MAPBGA                          [$10.10]
• _M52235 256k FLASH/32k SRAM 60MHz 112LQFP/121 MAPBGA                          [$12.00]
• _M52236 256k FLASH/32k SRAM 50MHz 80LQFP                                      [$6.20]

_M5225X family FEC + USB-OTG

• _M52252 256k FLASH/32k SRAM 66/80MHz 100LQFP                                  [$5.40]
• _M52254 512k FLASH/64k SRAM 66/80MHz 100LQFP                                  [$5.90]
• _M52255 512k FLASH/64k SRAM 80MHz 100LQFP                                     [$7.90]
• _M52256 256k FLASH/32k SRAM 66/80MHz 144LQFP/144MAPBGA                        [$6.40]
• _M52258 512k FLASH/64k SRAM 66/80MHz 144LQFP/144MAPBGA                        [$6.80]
• _M52259 512k FLASH/64k SRAM 80MHz 144LQFP/144MAPBGA                           [$8.80]

USB-OTG
M5221X, M5222X and M5225X devices all have USB OTG

Ethernet EMAC/PHY
M5223X has internal EMAC and PHY. M5225X has internal EMAC but requires and external PHY.

Relaxation oscillator
The M5223X doesn’t have an 8MHz relaxation oscillator.
The M521XX and M5221X have in addition the possibility to use the RTC oscillator as system clock input

UARTS
M52100 and M5221X have 2 UARTs (exception M52211 has 3 UARTs)
M521X, M52110, M5222X, M5223X and M5225X have 3 UARTs

I2C
M5225X devices have 2 I2C interfaces.
M521XX and M5221X have 2 I2C interfaces. Using I2C1 however stops use of QSPI.
M521X, M5222X and M5223X have 1 I2C interface

RTC
M521XX, M5221X and M5225X have battery backup for RTC and SRAM. Using the RTC crystal however stops use of UART0 on the M521XX and M5221X, whereas the RTC oscillator has dedicated pins on the M5225X
M521X doesn't have a RTC.

RAM standby
M521XX, M5221X, M5222X and M5225X have battery backup RAM capability. In devices with more than 16k SRAM only the first 16K is backed up.

FlexCAN
M5211 (in 64 QFN package), M5213, M52231, M52234, M52235, M52255 and M52259 have a FlexCAN module (plus the 66MHz version of all other M5225X family)

Mini-Flex Bus
M52255, M52258 and M52259 have an 8-bit Flex-Bus with 2 chips select lines and up to 1GByte (20bit) address range. In multiplexed mode it can operate in 8-bit or 16-bit data bus mode.

CAU
The M52235, M52255 and M52259 have a Random Number Generator and Crypto Acceleration Unit

Edge Port (IRQs)
The M521X, M521XX, M5221X and M5222X have 7 IRQs (IRQ1..IRQ7) with exception of the 64 pin packages which have only 3 (IRQ1, IRQ4 and IRQ7)
The M5225X have 4 IRQs (IRQ1,3,5 and 7)
The M5223X has 15 IRQs (IRQ1..IRQ15) with the exception of 80 pin packages which have only 4 (IRQ1, IRQ4, IRQ7 and IRQ11)

Backup Watchdog Timer (BWT)
The M521XX, M5221X and M5225X devices contain a Backup Watchdog Timer, which enables improved performance compared to the Core Watchdog, which is integrated in the System Control Module of all devices.

217

Luminary Micro ^TM LM3SXXXX / LM3SXXXX Service pack 1 now available

« on: April 19, 2008, 12:55:46 PM »

Hi All

Please note that the Service Pack 1 for the LM3SXXXX is now available on the SP page: http://www.utasker.com/software/softwareV1.3.html

This service pack adds both SPI FLASH [ATMEL and ST] support for the uFileSystem (or other data) and the Bare-Minimum-Boot-Loader support, allowing complete [and optionally encrypted] firmware updates via Ethernet (FTP or HTTP Post).

A new boot loader users' guide is being prepared (watch the documents page) which will contain full details, but if you want to use it already here is a very brief guide:

SPI FLASH:
- this is easy. Connect a chip as in the circuit diagram here: http://www.utasker.com/docs/uTasker/spi_flash_luminary.PDF. Then configure SPI_FILE_SYSTEM + FLASH_FILE_SYSTEM. This will set the parameters to the end of internal FLASH and the uFileSystem to external SPI FLASH.

Boot loader:
- Use the Rowley project in Applications\uTaskerBoot to build the boot loader itself (a pre-compiled binary is also included).
- Use the build configuration "Bare Minimum Boot" when building the uTasker project.
- Run the bat file "BM-Convert.bat" in \Applications\uTaskerV1.3\Rowley_LM3SXXXX\Bare Minimum Boot Loader to merge the boot loader with the application. This will generate a binary file (uTaskerBM.bin) which can be downloaded to the board using LM Flash Programmer.
- After making changes to the application in the same project, always re-run the BM-Convert.bat, which also makes a file called "z_Upload.bin". This can be loaded to the board via Ethernet (best use the upload method on the "admin" web page. You should find that uploads complete within about 7s!!

Good luck!!

Regards

Mark

218

NXP^TM M522XX, KINETIS and i.MX RT / Inaccuracy in M5223X PIT TICK

« on: April 18, 2008, 08:07:20 PM »

Hi All

Some long period accuracy measurements suggest that there is a error in the setting of the TICK period (using the PIT) up to and including SP6.

According to latest information the value TICK_DIVIDE is 1 too large to achieve the most accuracte value
PIT_PMR_0 = TICK_DIVIDE;
and so shoudl be
PIT_PMR_0 = (TICK_DIVIDE - 1);

Working with 50ms TICK (TICK_RESOLUTION) this makes a difference of about 9s in an hour.
Once this has been fully confirmed it will be corrected for ready for the next SP, but it can easily be improved if you would like to test it yourselves.

See also the following for more details of the TICK accuracy.
http://www.utasker.com/forum/index.php?topic=193.msg708#msg708

Regards

Mark

219

NXP^TM LPC2XXX and LPC17XX / LPC23XX Service Pack 3 now available

« on: April 06, 2008, 03:22:51 AM »

Hi All

Please note that the Service Pack 3 for the LPC23XX is now available on the SP page: http://www.utasker.com/software/softwareV1.3.html

This is an important service pack since it adds both SPI FLASH [ATMEL and ST] support for the uFileSystem (or other data) and the Bare-Minimum-Boot-Loader support, allowing complete [and optionally encrypted] firmware updates via Ethernet (FTP or HTTP Post).

A new boot loader users' guide is being prepared (watch the documents page) which will contain full details, but if you want to use it already here is a very brief guide:

SPI FLASH:
- this is easy. Connect a chip as in the circuit diagram here: http://www.utasker.com/docs/uTasker/spi_flash_lpc.PDF. Then configure SPI_FILE_SYSTEM + FLASH_FILE_SYSTEM. This will set the parameters to the end of internal FLASH and the uFileSystem to external SPI FLASH. Be sure to use the new web pages in the new folder WebPagesSPI since they are suited to the smaller granularity SPI FLASH.

Boot loader:
- Use the Rowley project in Applications\uTaskerBoot to build the boot loader itself (a pre-compiled binary is also included).
- User the build configuration "Bare Minimum Boot" when building the uTasker project.
- Run the bat file "BM-Convert.bat" in \Applications\uTaskerV1.3\Rowley_LPC23XX\Bare Minimum Boot Loader to merge the boot loader with the application. This will generate an Intel Hex file which can be downloaded to the board using Flash Magic.
- Be sure to use the new web pages in the new WebPagesUpload folder when working with this configuration [a new document in \Applications\uTaskerV1.3\WebPages\WebPagesLPC23xx\FileSystem explains the exact file system configuration], which has 336k space with 136k of it reserved for firmware uploads.
- After making changes to the application in the same project, always rerun the BM-Convert.bat, which also makes a file called "z_Upload.bin". This can be loaded to the board via Ethernet (best use the upload method on the "admin" web page. You should find that uploads complete within about 5s!!

Good luck!!

Regards

Mark

220

Luminary Micro ^TM LM3SXXXX / Ethernet based firmware upload to Luminary

« on: April 04, 2008, 10:48:58 PM »

Hi Luminary Fans!!

I am very proud to inform you that today I completed a boot loader (the uTasker Bare-Minimum-Bootloader) for the LM3S6965. It allows complete firmware upgrades via Ethernet (using FTP or HTTP post) and occupies from 2 x 1k FLASH sectors, taking up about 1.7k of actual space (about 1.9k when encrypted upload is enabled).

I tested on the Luminary LM3S6965 Ethernet evaluation board with a 156k file system configured, where the last 94k of it is reserved for accepting the new firmware. This corresponds to a typical configuration, allowing medium code size, 62k of dedicated web pages, a parameter system to comfortably work on the chip and remote upgrades to be made via the Internet without any need for external support (eg. using SPI FLASH).

The development took place purely using the uTasker simulator until I was reasonably sure that the operation was correct. There were a couple of hitches when moving to the target HW caused by the method needed to jump from the boot loader to the application code, plus an endian issue which was not encountered in the simulator.

Otherwise the development went fairly smoothly, aided by the fact that I am still fresh from the same exercise for the LPC project. I again set up the bootloader project using Rowley to fit together with the Rowley uTasker build seeing as this is proving to be the most popular development environment for this chip too.

To avoid surprises with programming times during the boot phase I went straight to 50MHz operation and the programming time for 50k of code was measured at about 3s (comparing with about 1.5s with the 72MHz LPC). This still enables fast firmware uploads where the complete upload time from pressing the browser upload button to establishing communication with the new code is still well below the 10s mark (around 7s).

Since the development version now includes the boot loader and SPI FLASH support for both ATMEL and ST devices I do believe a new service pack would be very worth while - a little new documentation is required but this could be ready quite shortly!!

Regards

Mark

221

NXP^TM LPC2XXX and LPC17XX / Ethernet boot-loader for the LPC23XX

« on: April 04, 2008, 01:08:04 AM »

Hi All

I am very proud to inform you that today I completed a boot loader (the uTasker Bare-Minimum-Bootloader) for the LPC23XX. It allows complete firmware upgrades via Ethernet (using FTP or HTTP post) and occupies one 4k FLASH sector, taking up about 2k of actual space (about 2.9k when encrypted upload is enabled).

I tested on the MCB2300 with a 336k file system configured, where the last 136k of it is reserved for accepting the new firmware. This is a useful configuration since this allows a fairly big code with 200k of web pages, a parameter system to comfortably work on the chip and remote upgrades to be made via the Internet without any need for external support (eg. using SPI FLASH).

The development took place purely using the uTasker simulator until I was reasonably sure that the operation was correct. The first test on the target failed because of the boot loader being linked using the false linker script file... the second attempt worked so I was very happy (and a little relieved).

The only thing that I am a little unsure of is the time it takes for the actual programming it complete (check of the new code, delete of old code, programming of new code to program space and delete of the back-up) taking around 9s. I don't program the PLL during this operation so it is running (I believe) directly from the 12MHz crystal. I am wondering whether there would be an improvement in running the PLL at full speed or whether the time lost is waiting for the FLASH operations to complete (which is probably not clock speed dependent).

I set up the bootloader project using Rowley to fit together with the Rowley uTasker build seeing as this is proving to be the most popular development environment for this chip.

Since the development version now includes the boot loader and SPI FLASH support for both ATMEL and ST devices I do believe a new service pack would be very worth while - a little new documentation is required but this could be ready quite shortly!!

Regards

Mark

Note: I also checked everything on the OlimexLPC-2378-STK and it worked correctly. On this board the reprogramming time was about 12s - I wonder why the difference? The actual uTasker demo project is around 55k in size and so the actual upload time via LAN is hardly noticable (almost instantaneous).

222

Luminary Micro ^TM LM3SXXXX / Cortex M3 and ARM news

« on: April 02, 2008, 01:25:43 AM »

Hi All

I have just been reading an article where the CEO of ARM, Warren East, admitted that the progress with the Cortex M3 core has been slow. In terms of unit shippments it stood at just over 100'000 around the beginning of 2008 (I wonder how many of these are chalked down to Luminary??).

However he said that momentum is picking up. Obviously, as well as STMicroelectronics, other larger microcontroller suppliers - NXP and Toshiba - are now also licensees for the M3.

A rather strange statement is then quoted from the general manager of the microcontroller product line at NXP, Geoff Lees, who says that their ARM7 family has been a runaways success and there is a huge demand for ARM cores.
But then... "I don't see than much difference between the specific cores, just a general demand for ARM"
Hmmm.... Is that a typical manager type statement or does he know something we don't??

Regards

Mark

223

NXP^TM LPC2XXX and LPC17XX / NXP news - new ARM9 baseddevices

« on: April 02, 2008, 01:13:44 AM »

Hi LPC fans

NXP has made a new announcement about some more chips that will be available shortly. LPC3200 family of microcontrollers will be sampling in April with volume shipping in Q3 2008. Demos will be available at the Embedded Systems Conference (ESC) in San Jose April 14-18, 2008.

Designed for flexibility in applications that require fast, simultaneous communications, the LPC3200 combines high-performance, low power consumption and a myriad of peripherals. The features include I2C, I2S, SPI, SSP, UARTs, USB, OTG, SD, PWMs, A/D with touch-screen interfaces, 10/100 Ethernet MAC and a 24-bit LCD controller that supports STN and TFT panels. The family supports DDR, SDR, SRAM and Flash memory devices and provides the option of booting-up from NAND Flash, SPI memory, UART or SRAM.

Get the full press release here:
http://www.nxp.com/news/content/file_1421.html

LPC2478 was recently nominated as the EDN Innovation Product of Year finalist in 2007.

Regards

Mark

224

Luminary Micro ^TM LM3SXXXX / SPI FLASH support for the LM3Sxxxx

« on: March 30, 2008, 03:06:06 AM »

Hi All

Here's a note to say that I have successfully added SPI FLASH support to the LPC project - see
http://www.utasker.com/forum/index.php?topic=230.0

The reason why I am announcing this in the Luminary section is due to the fact that I have in fact added the same support (in parallel) to the Luminary project, but not tested it on the HW just yet (simulation works correctly).

I decided to solder an ATMEL AT45DB041B on to the LPC board first to check that all works. Now that this is operating correctly (after a couple of extra instructions to ensure the RX FIFO was correctly being cleared) I am assuming that the luminary project will also operate correctly when I solder its chip into position, probably some time tomorrow. The reason for the optimism is explained in the link above...!

Regards

Mark

225

NXP^TM LPC2XXX and LPC17XX / SPI FLASH support for the LPC23XX

« on: March 30, 2008, 02:58:47 AM »

Hi All

Here's a note to all LPC fans that I now have the following SPI FLASH support operational:

LPC2378 512k internal FLASH configured to use the last 2 sectors as parameter blocks.
An external SPI FLASH (ATMEL) 512k is connected to SSP1 to act as uFileSystem. SSP is clocked at 9MHz although it could go faster. The web pages are being copied correctly and server by the web server, so looks good!

This is in fact the first time that I have used the SSP, rather than the SPI. The SSP is more flexible and has 8 word deep rx and tx FIFOs. The main reason that I chose this is, however, that the pins are better positioned than the SPI pins, which can easily be lost if all UARTs are required.

A second reason why this choice is practical is due to the Luminary device (which I am working on in parallel). It has an SPI (as they call it), but it is in fact absolutely identical to the SSP in the LPC! Even the internal registers and bits are the same, so this is a bit like 'killing two birds with one stone...!'

Regards

Mark