Topics

241

NXP^TM LPC2XXX and LPC17XX / LPC210X Executables available

« on: January 08, 2008, 11:14:32 PM »

Hi All

Since the LPC23XX is in fact a super-set of the LPC210X which I have previously used (and still do...) I decided to add executables for them.

If you are interested in these chips check them out on the following page:
http://www.utasker.com/Demos/exes/exes.html

The package included LPC2101, LPC2102, LPC2103 (in LQFP48 and PLCC-44) plus LPC2104, LPC2105 and LPC2106).

Regards

Mark

242

ATMEL^TM AT91SAM7X and AVR32 / New Service Pack SP2 for SAM7X

« on: January 02, 2008, 11:11:00 PM »

Hi All

Here is news of the release fo a new service pack for the SAM7X.

This new SP brings this project up to date with the newest uTasker developments. It include latest features like NetBIOS, VLAN, Fast serving HTTP, RARP and passive FTP, plus DMA UART and SPI FLASH based file system (as well as various more subtle improvements …bug fixes are another name for them..).

The latest version is available on the service pack page (http://www.utasker.com/software/softwareV1.3.html ) with complete release notes. This version includes projects for IAR, stand-along GNU, Eclipse GNU and Rowley Crossworks – the standalone GNU can be automatically build from the VS based simulator environment!

Good luck!

Regards

Mark

243

ATMEL^TM AT91SAM7X and AVR32 / Peripheral DMA

« on: December 24, 2007, 05:28:13 PM »

Hi All

Before releasing a new service pack for the SAM7X (which is in the last stage of preporation) I have decided to add some support for the peripheral DMA controller.

This is in the form of DMA support for the serial interfaces (USARTs). Below is a report on the peripheral DMA controller as found in the SAM7X and some details about the USART DMA driver integration.

Regards

Mark


********************************************************************************

Peripheral DMA Controller

The AT91SAM7X has 17 peripheral DMA channels. Each channel is defined for use by a certain transfer direction of a certain serial peripheral device. This means that all serial peripheral devices have the capability of using DMA rather than interrupt or polling operation without restrictions to the number of general purpose DMA channels allocated to such peripherals.

The DMA transfers are always between a serial peripheral device and memory, whereas the memory could be internal or external memory (if the device were to support external memory).

The AT91SAM7X does not support DMA transfer between two memory locations, as is used to optimise data moves in some systems (eg. uMemcpy with DMA support).

The control registers for the DMA channel belonging to the peripheral are always positioned at an offset of 0x100 from the start of the peripheral control block. A counter value enables a block transfer of up to 64k bytes to take place. A next counter value then allows a follow on transfer to already be prepared while the present transfer is still in operation. When a transfer completes it is possible to program it to generate a peripheral interrupt.

USART Tx

A useful application of DMA is when sending blocks of data to the serial interface. Rather than having to handle an interrupt for each character sent, only one interrupt is required to signal that a complete block was sent. The block can be up to 64k in size (assuming there is enough data memory to prepare such a block prior to transmission.

This support has been added to the V1.3 SP2 version of the uTasker for the SAM7X. To activate the DMA support, the define SERIAL_SUPPORT_DMA needs to be activated (app_hw_sam7x.h). Although the code is then available, the use of DMA transfer is still selected on a per-interface basis. The following additional configuration activates the mode when a USART is configured:

    tInterfaceParameters.ucDMAConfig = UART_TX_DMA;  // activate DMA on transmission

A value of 0 should be set if the DMA option is not to be used.

The internal operation of the peripheral DMA is based on two flags in the USART status register. The first flag, TXRDY, signals that the transmitter can accept a transmit character – this flag is used in character interrupt mode to cause an interrupt to be generated in order to load the next character. Since the flag is usually set – it is only 0 while there is actually a character transmission in progress – the interrupt is thus only enabled when character transmission is actually in progress. When performing transmission with peripheral DMA support this interrupt is never enabled – the flag is however used by the peripheral DMA controller to cause the next DMA transfer to take pace (when the DMA transfer count is not 0).

The second flag is not usually used when operating in character interrupt mode but signals that the DMA transfer has terminated in DMA mode. This flag is the ENDTX flag and is set whenever the DMA transfer count is 0, which is also the case when no actual transmission is in progress. Therefore the interrupt is only enabled when a block transmission is really taking place.

A block transfer is therefore configured by setting the DMA transmit pointer to the start of the block in data memory and then the DMA transfer count to the length of the data. Since the TXRDY flag is generally already set, the first data transfer starts immediately. On each transfer (controlled by the TXRDY flag after each character transmission) the DMA count value is decremented until it finally reaches 0 (after the last character in the block has been transferred to the USART transmit register). The ENDTX interrupt is called which is used to either initiate further block transfers of else terminate the sequence (in this case it disables further ENDTX interrupts since the ENDTX flag will remain active).

This solution results in a simple and compatible interface for the uTasker serial driver. The “next DMA” capability was not used since its benefits are negligible in comparison to its additional complication and the otherwise interface incompatibility.


USART Rx

Generally, DMA for USART reception is not as useful as for transmission. The transmission case can be activated without any implications for the application since the interface and its operation are effectively identical. The advantage is in the DMA driver efficiency since it avoids interrupt handling of each character.

Receive DMA operation requires programming the length of receive data blocks, whereas a block size of 1 will give no improvements over character interrupt mode. Larger block sizes will however result in improved character reception performance but the data will only be available once the complete block size has been received or else a timeout has occurred. Although the SAM7X USART implementation supports hardware timeouts, the solution is not generically compatible and so is generally avoided. Rx DMA operation is thus not very suited to applications which receive occasional single characters (eg. the input from a keyboard) and also has problems with XON/XOFF operation since such sequences are also queued by hardware in the input buffer before a complete DMA block size has been received.

Receive DMA is however useful when the serial protocol operates using frames of fixed sizes, resulting in an optimal efficiency due to the fact that there is only one interrupt when the complete frame has been received. The uTasker serial driver supports this mode of operation and the USART RX DMA can be defined to operate as follows:

    tInterfaceParameters.ucDMAConfig = (UART_RX_DMA | UART_RX_DMA_HALF_BUFFER);

This will set up each receive block to received a length equal to half of the receive buffer length. The receive buffer length should thus be defined to be twice the frame length. Each time the frame length has been received to the input buffer, the driver will wake the owner application task, which can then read the contents. In the meantime the second half of the buffer is being used for reception of the next frame so that there are generally no critical time requirements for the application to read the first frame buffer.

The reception DMA process is analogue to the transmission process. Instead of using the RXRDY flag, which is used in character interrupt mode to signal each arrived character, this is used by the peripheral DMA controller to initiate each DMA transfer. While the DMA block transfer is still in progress the ENDRX flag is 0. As soon as the DMA transfer count reaches 0, when the last character in the rx block has been written by DMA to the receive buffer, the ENDRX flag is set and its interrupt is used to update the receive buffer details and signal that the application can retrieve the received data from the input buffer.


The uTasker simulator has also be updated to handle the USART transmit and receive operation in DMA mode so that the operation can be comfortably tested on the PC.

244

NXP^TM LPC2XXX and LPC17XX / LCP2378 FLASH + Demo put on-line

« on: December 10, 2007, 12:45:20 AM »

Hi All

After spending this weekend working out the details of the uFileSystem on the LPC23XX I am proud to be able to anounce a first LPC2378 demo on line at http://demo.uTasker.com

Here are my notes about the FLASH and the porting work.

Comments welcome!

Regards

Mark



***************************************************************


FLASH

The LPC23xx has up to 512k internal FLASH memory. In the case of the 512k part, the last 8k are not useable since they are required by the internal boot loader.

Now I do have a small advantage here due to the fact that I have used the FLASH in the LPC21xx range of processors a few years ago and also wrote a production loader which communicates with the internal boot software, checks its version number, loads a new version if it find that the original one is too old, and then loads the application code. At the time I knew most of what was needed to know. Since that was however about 3 years ago I have had to re-read to get up to speed again.

Before continuing with porting the uFileSystem to work together with the LPC23xx internal flash it is worth mentioning some details which were made available from a Philip’s application engineer, which give some extra details to understanding how the FLASH is special and some of its restrictions. I have never seen these details in the normal data sheets or users’ manuals but recommend anyone new to the FLASH in the device to check it out! See it here: http://tech.groups.yahoo.com/group/lpc2000/message/2681

Before getting started with the real work, there are two things which will certain cause some complications:

1 - The FLASH granularity is quite large and the actual size varies with the sector number. This makes for some complications because the file system may need to know that granularity is not fixed (all other chips supported up to now have had a fixed FLASH granularity – eg. 256 bytes in the SAM7X up to 64k in the STR91). The first few sectors in the devices are 4k in size, followed by a few 32k sized sectors. The 512k version then has some further 4k sectors towards the end of the FLASH memory range. The large granularity option (sub-file system) in the uTasker project will probably have to be activated for this device.

2 – Data in lines of 16 bytes can not be modified after being written (due to ECC bits in each line). This means that the strategy of marking blocks as being valid will have to be changed to respect this.

3 - Each 4k aligned area can only be written to a maximum of 16 times before it must be erased. I don’t know whether this cause a problem at the moment…

4 – Flash should be programmed in 256 byte blocks (or some larger multiples of this), whereby unaltered bits are best programmed with ‘1’ even if they are already ‘0’.

All in all the FLASH is a little bit trickier to use than in most other chips.

In order to simplify the operation with the FLASH, a fixed 256 byte buffer was set up in RAM to use as preparation and write buffer.


In Application Programming (IAP)

The chip includes pre-installed routines for performing in application programming (writing and erasing FLASH memory). When these routines are operating the FLASH is not accessible, so interrupts are blocked when operation is passed to these functions. In addition, it is important to know that the functions use 32 bytes of memory at the top of internal SRAM – for this reason the stack pointers are not initialised to the top most value in SRAM but 32 bytes below it.

In order to pass operation to the IAP routines execution of its program (at 0x7ffffff0) is started. Parameters to the IAP are passed on the stack and it returns results of its operation on the stack.

The IAP operation was found to work very well and the uTasker simulator was extended to simulate the internal IAP operation, including carefully checking passed parameters and sequences to ensure that any error in use could be immediately seem.

The file system was set up to 176k in size for the first tests, which enabled verification of operation with mixed flash sector sizes (5 x 32k sectors and 4 x 4k sectors). The changes in the file system interface were fortunately quite painless and the sub-file system was found to be suitable.

File writing required holding the first FLASH line (16 bytes – quad word) in a temporary buffer until the end of the file had been reached and its size know. As the file was closed the first line, including MIME information and file length, were saved – this is special due to the FLASH operation as discussed previously. A further advantage of file writing is that the writes are always sequential (apart from at the end); that means each byte is simply at the next address (they don’t jump around). This made the management of the FLASH row buffer and the commits to FLASH quite simple; every time a FLASH row boundary was passed the buffer could be written. Right at the end of the file, any open buffer could be additionally committed.  After testing FTP and HTTP in the uTasker simulator (and of course implementing and debugging the integration of the new FLASH driver) it was time to give it a shot on the hardware. This worked first time so I moved on to the parameter system, thinking that the work was practically over.

Now the parameter system did in fact prove to be a little more complicated than expected. Not due to the fact that its operation was more difficult but due to the fact that a decision had to be made about how best to implement it, based on the fact that bytes can not be modified at any address – the rule about the 16 byte line again…

Since the purpose of the parameter system is no for absolute efficiency but rather for highest reliability, where the user can modify system parameters either in a temporary or permanent way with the security that no data can be lost - even if there is a power down during the sequence – there was really only one way to do it. This was to use one FLASH line (16 bytes) to save each byte of user parameter data. This is very inefficient since only 256 bytes of user parameter data can be saved in a 4k FLASH sector (the smaller ones are of course pre-destined for this use – I configured the last 2 to work as a swap block). This does however allow random writes to be made to the parameter system, which is important as its use is not sequential as is file access. It hurts to be so wasteful of memory but on the other hand it is good to know that the parameter system remains bullet proof, which is the most important point.

To avoid unnecessary writes, additional checking code was added to not write unmodified data to the internal FLASH. This reduces actual write cycles to the minimum required and so should avoid any issues of maximum writes before deletion. The swap buffers always delete when tidying up after adding new parameter data which fits well.

So with that exercise behind me I activated a few more services like SMTP to perform email tests and an HTTP GIF image upload test and have put the LPC2378 board on line to see how it performs.

245

Freescale^TM MC9S12NE64 / A chance to show your innovative product

« on: December 04, 2007, 08:42:51 PM »

Hi All Freescale users

Here's a quick note about a potential opportunity to show case your own product at a major exhibition (EMBEDDED WORLD 2008 (Germany, Nurnberg, Feb 26-28)) and this is even completely FREE of charge.

The requirement is that it shows a Freescale part (like the NE64) being used in a product which looks good and can be described as an "innovative" solution. Freescale has a large presence there and have some glass cabinets in which they are willing to show such customer projects.

If your project qualifies, this could be an opportunity to get it displayed to visitors at this major event. If you are interested please contact me so that I can forward the suggestion directly to the organisers (note that the selection will start in the next few weeks!).

Regards

Mark

246

NXP^TM M522XX, KINETIS and i.MX RT / A chance to show your innovative product

« on: December 04, 2007, 08:42:12 PM »

Hi All Freescale users

Here's a quick note about a potential opportunity to show case your own product at a major exhibition (EMBEDDED WORLD 2008 (Germany, Nurnberg, Feb 26-28)) and this is even completely FREE of charge.

The requirement is that it shows a Freescale part (like the M5223X) being used in a product which looks good and can be described as an "innovative" solution. Freescale has a large presence there and have some glass cabinets in which they are willing to show such customer projects.

If your project qualifies, this could be an opportunity to get it displayed to visitors at this major event. If you are interested please contact me so that I can forward the suggestion directly to the organisers (note that the selection will start in the next few weeks!).

Regards

Mark

247

µTasker general / New Device Executables for demo or port configuration checking

« on: December 02, 2007, 10:29:00 PM »

Hi All

There has been an addition made to the demos on the web site which now enable everyone to see a running device on his/her own PC without the need to have the complete projects and also without the need to perform any installations.

The first chips which have been made available in this form are from the LM3SXXXX family, including LM3S1968, LM3S6965 and LM3S8962.

The demo project can thus be tested in much the same way as when using the simulator together with VisualStudio.

Or, the simulated device can be used to check the ports on the device of interest and compare their layout and functionality between devices within the family.

Please check out the new page at:
http://www.utasker.com/Demos/exes/exes.html

Simply copy and extract the files and run the exectable - eg. uTaskerV1-3_LM3S6965.exe to see the LM3S6965 in operation, or uTaskerV1-3_LM3S8962.exe to see the LM3S8962 running.

This is the first attempt to do this - it may be necessary to have Winpcap installed (although I am not absolutely sure since all my PC already have it...).

Tell me if there are any problems. Once it is sure that all is well it will be worth while extending this to more types.

Regards

Mark

248

Luminary Micro ^TM LM3SXXXX / Luminary Stellaris executables - try them out!!

« on: December 02, 2007, 10:27:49 PM »

Hi All

There has been an addition made to the demos on the web site which now enable everyone to see a running device on his/her own PC without the need to have the complete projects and also without the need to perform any installations.

The first chips which have been made available in this form are from the LM3SXXXX family, including LM3S1968, LM3S6965 and LM3S8962.

The demo project can thus be tested in much the same way as when using the simulator together with VisualStudio.

Or, the simulated device can be used to check the ports on the device of interest and compare their layout and functionality between devices within the family.

Please check out the new page at:
http://www.utasker.com/Demos/exes/exes.html

Simply copy and extract the files and run the exectable - eg. uTaskerV1-3_LM3S6965.exe to see the LM3S6965 in operation, or uTaskerV1-3_LM3S8962.exe to see the LM3S8962 running.

This is the first attempt to do this - it may be necessary to have Winpcap installed (although I am not absolutely sure since all my PC already have it...).

Tell me if there are any problems. Once it is sure that all is well it will be worth while extending this to more types.

Regards

Mark

249

Luminary Micro ^TM LM3SXXXX / FLASH memory

« on: December 02, 2007, 12:54:46 AM »

Hi All

Here is a short report on first experiences with the FLASH memory when porting the uFileSystem to the new LM3S6xxx project.

This demo is now on-line at http://demo.uTasker.com so please visit it. It supports the standard uTasker demo project including
email test.

Comments welcome!

Regards

Mark


FLASH memory

The LM3S6965 has 256k of internal FLASH memory. The memory is used for program code and for the uFileSystem. Its granularity of 1k is fairly good, making file system work very easy. It also allows protection of 2k blocks against being read using a debugger or against erasure and programming. Since the protection can be set only once and then never removed, I didn’t try testing it – it is however there for hyper-sensitive users who want to be able to one-shot their code to the device so that it can never be read if falling in to the hands of their competitors.

The actual FLASH size available on the chip can be determined by reading the DC0 (Device Capabilities) register.

The only thing to be respected when using the FLASH is that it has to be written using aligned long words and deleted at 1k boundaries. Bits within a long work can individually be programmed to ‘0’, which makes it very flexible.

The programming is extremely simple: set the address to be modified to the FMA register; set the long word to be written to the FMD register and then command it using the FMC register. Wait about 50us (polling the FMC register to see when it is ready) and then do the next job.

1k page erasure takes about 25ms following more or less the same procedure, whereby no data has to be set.
The only other configuration required is to set the USECRL with the correct microsecond value to suit the present operating frequency.

It was thus not that complicated to set up the uFileSystem to operate together with the LM3S6965. I chose a 160k file system size with 2k parameter swap blocks for safely saving updatable user parameters and 156k uFileSystem file space with a 4k file granularity.

One thing which was not clear was whether the FLASH can still be accessed during program and erase operations. The data sheet doesn’t seem to specifically mention this although in the Luminary Micro forum someone states that it is there somewhere. So I played safe and copied the FLASH routines to SRAM and executed then there with protection against interrupts. Once everything seemed to be working correctly I then had a shot of simply running the routines from FLASH without any protection. Normally it will immediately crash if the whole FLASH memory is not available for reads during the operation, but the code seemed to work. So I have left it just like that until some problem is experienced or I can verify that this technique is advised.

With the uFileSystem operational, the HTTP and FTP servers could be activated and files loaded. In addition some other things like DNS, NetBIOS, HTTP POST, Time Server and SMTP were activated, giving a code size or around 31k – just a bit short of the IAR Kick Start limit of the compiler/debugger I am playing with. This was put on line to get an idea of its stability – visitors can command a welcome email from the device and play around with various controls and configurations.

250

NXP^TM LPC2XXX and LPC17XX / Ethernet controller

« on: November 25, 2007, 05:06:23 PM »

Hi All

Since I (finally, after some battling with the PHY) have the Ethernet controller in action, here's a report on what I did and what I found.

Comments welcome!

Regards

Mark


Ethernet Controller

The LPC2378 contains an Ethernet controller but this requires an external physical layer interface device (PHY) and the National Semiconductor’s DP83848 is used on the MCB2300. The PHY is connected via RMII (Reduced Media Independent Interface) rather than MII, but not because the MII mode is not possible. The RMII mode saves some pins: where the MII mode defines 16 pins, the RMII needs only 6 to 10.

In order to achieve the same throughput as MII the RMII needs a faster clock (50MHz rather than 25MHz).
When configuring the Ethernet controller, the RMII ports are configured for their peripheral operation. The Ethernet module is powered up and the MII management clock set to 2.5MHz (the DP83848 can actually communicate up to 25MHz but the specification stipulates 2.5MHz). The ID of the PHY is read to ensure that this is correctly identified before continuing. The PHY address on the MCB2300 is 1 – it is possible to connect up to 31 PHYs on the RMII, determined by input states to the DP83848 at reset.

Due to a bug in the first silicon, a workaround is needed to get the RMII mode operating. This involves checking the MAC module ID, to see whether the workaround is needed, and configuring P1.6 in the PINSEL2 register to be ENET-TX_CLK. P1.6 can therefore not be used for other functions if it is not sure that the chip is at least an A revision.
To ensure that the PHY is operating correctly, its identifier is requested and checked with the identifier expected from the PHY type.

Since the interrupt output from the DP83848 is not connected to the processor on the MCB2300 no link state change interrupt was integrated.

The LPC2378 has 16k of RAM which is specially positioned on the internal bus to allow it to be used optimally by the Ethernet controller. This RAM is not grouped together in the memory map with the other RAM modules in the chip and so it was decided to use it especially for the Ethernet. A special memory allocation routine (uMallocLAN_Align()) was added to support this and the user can specify how many receive buffers and how many transmit buffers are allocated there. Since there is space for 10 full size Ethernet buffers a good choice would be 6/7 for reception and 4/3 for transmission – but this is not possible when working with the first silicon due to a problem with the receiver not being able to handle more than 4 buffers. If the chip is at least a revision A type this restriction no longer applies.

The project was thus set up to use 4 receive buffers and 6 transmit buffers in the Ethernet RAM space. If it is sure that only newer devices are in use this can be modified to use more receive buffers, since these are more critical.

As well as the Ethernet data buffer space in the Ethernet RAM, a status block and a buffer descriptor is created in the same RAM for each receive and transmit buffer.

The MAC address is set to the registers SA0, SA1 and SA2.

The first exercise was to be able to respond correctly to ARP and PING requests. No transmit interrupt was required since the transmit buffer descriptors hold information about how far the transmission of open buffer has progressed.

Each frame reception generates an RX_DONE interrupt and this interrupt was used to wake the Ethernet reception task to process the contents of the frame. Once the frame had been processed, the user index (receive consumer) is incremented to the next buffer.

During the ARP response transmission the operation of the PAD_CRC_ENABLE (padding enable) was verified. This is a feature which allows Ethernet frames of less than 60 bytes to be automatically padded to the minimum length. This was verified to be padding with zeros up to the minimum Ethernet frame size of 60 bytes. Padding with zeros is important to avoid broadcasting the remains of previous TX FIFO buffer content, which can represent a security risk in some applications. Since the device does this correctly, no manual padding is required.

It can be concluded that the Ethernet controller in the LPC2378 is a powerful solution with high speed RAM dedicated to the job of transmitting and receiving the frame contents. 16k Ethernet RAM allows fairly generous buffer space. Due to a bug in the original silicon, the limit to the number of receive buffers means that this can not be utilised optimally but when using revised devices this is no longer an issue.

The Ethernet controller supports various powerful features which haven’t been discussed here (eg. the various set ups to receive certain types of unicast and multicast and wake up frames). Although the use of the receive and transmit buffers is very simply, the complete set up is a little more complicated due to its range of capabilities. Some of the modes are not that easy to understand and may require quite a lot of experimenting to set up and use correctly.

The present solution state uses standard configurations which have proved to work reliably during the first ARP/ICMP PING test phase.

The next step is however to add the uTasker HTTP and FTP servers. These require the uFileSystem to be able to do anything useful so this requires the porting of the uFileSystem and parameter system – involving manipulating internal FLASH, which is the next step in the development process.

251

Luminary Micro ^TM LM3SXXXX / Ethernet Controller with PHY

« on: November 23, 2007, 02:20:14 AM »

Hi All

Since I have the Ethernet controller in action, here's a report on what I did and what I found.
Comments welcome!

Regards

Mark



Ethernet Controller with PHY

This is certainly the most interesting part of the LM3S6965. It has not just an integrated Ethernet controller but also an Ethernet physical interface device, which promises to make the device extremely attractive.

The Freescale M5223X devices also have these on-board but its physical interface device doesn’t perform automatic MDI/MDI-X cross over correction which allows connecting with either a straight or cross-over cable. This avoids troubles with cable types when connecting directly or via a switch/hub and is therefore a big plus point.

Slightly surprising is the fact that the MDO line on the internal MII interface (the MDIO signal) needs an external 10k pull-up resistor to operate correctly. This MDIO signal is the only one available externally on its own dedicated pin.

Unlike the M5223X, which requires a single 25MHz crystal so that it can accurately generate the required internal Ethernet clocks, the LM3S6965 requires two crystals: One for the CPU and a second of 25MHz for the PHY.

There is no physical address (usually a 6 bit value) to address the PHY since there is only one possible PHY in the system – the M5223X for example can be configured to use alternative PHYs by disabling the internal PHY and accessing the external one via MII lines multiplexed with GPIOs. An external MII interface allows other media interfaces to be used in stead of Ethernet - such as optical, wireless or power line modem etc.

The LM3S6965 contains dedicated TX and RX FIFO Ram for use with the Ethernet controller. The TX buffer can hold one frame to be transmitted and a number or RX frames, depending on the size of individual receptions. These buffers are each 2k in size – experience has shown that a number of RX buffers can be useful for avoiding overruns at the receiver so it will be interesting whether the 2k RX buffer may prove to be a weakness by this device…

FIFO accesses are long word accesses which makes it more efficient that a byte oriented interface.

Due to the FIFO operation, the receive software can not perform zero copy processing since the buffers can not be accessed in a memory mapped fashion. Also it is in interest of avoiding overruns to retrieve the data as fast as possible by copying it into a memory mapped receive buffer – the number of which could be configurable. The question is whether the Rx FIFO copy should be performed in the Rx frame interrupt routine or not. It is probably best to do it asap. to reduce the likelihood of Rx overruns but the interrupt will need to allow other interrupts to operate (in other words have quite a low priority in the system hierarchy) since the copy loop will inevitably take around 200us or so for full sized Rx Ethernet frames. Since the Cortex M3 code handles nested interrupts well, this should not be a big issue.

On the transmission side there is a small complication involved due to the fact that the length of the transmit frame must be put into the TX FIFO as the first 2 bytes. This can complicate since TCP/IP frames are often built up in packets (Ethernet frame, IP frame, TCP frame, TCP data etc.) and these packets are placed in to an output buffer (not necessarily in the same order as the packets to be sent) and the total length is not necessarily known until the complete frame has been constructed.

The FIFO operation is certainly less flexible but compatibility can be easily maintained by first constructing the frame in a buffer (this requires additional memory copies and the space for this buffer) and then copying it to the FIFO once it is complete in linear memory and the total length is known.

As long as the buffers are correctly aligned (long word boundaries) the actual FIFO copies are optimally efficient because they become long word copies without any byte manipulation.

The first exercise was to be able to respond correctly to ARP and PING requests and this was achieved by using the technique of copying the RX FIFO to a series of correctly aligned RX Ethernet frame buffers and building up the transmission data in a correctly aligned TX Ethernet frame buffer. The PHY was programmed to generate an interrupt on link status changes so that the present link state and speed is known.

During the ARP response transmission the operation of the PADEN (padding enable) was verified. This is a feature which allows Ethernet frames of less than 60 bytes to be automatically padded to the minimum length. This was verified to be padding with zeros up to the minimum Ethernet frame size of 60 bytes. Padding with zeros is important to avoid broadcasting the remains of previous TX FIFO buffer content, which can represent a security risk in some applications. Since the device does this correctly, no manual padding is required.

The LEDs (LED0 and LED1) are controlled by the PHY. If the control of the general purpose ports, which they share with, are configured to activate the peripheral function the LED0 lights on link OK and LED1 flashes on RX or TX activity. A variety of other LED functions can also be programmed in the PHY’s LED configuration register!

The basic operation of the Ethernet interface could be successfully verified. Although it is not the highest performance solution due to the FIFO operation and lack of DMA support directly to working memory, the PHY and MAC are very easy to use. A useful optimisation step, which will be looked at later, is to remove the present linear TX frame buffer and build up the layers of TCP/IP frames directly in the TX FIFO – this will avoid a memory copy stage but the frame length issue (as described above) will have to be solved – there are certainly tricks which can be worked out to do this somehow.

The next step is however to add the uTasker HTTP and FTP servers. These require the uFileSystem to be able to do anything useful so this requires the porting of the uFileSystem and parameter system – involving manipulating internal FLASH.

Ethernet Power Consumption

100M Ethernet operation involves a certain amount of power consumption. This often causes devices with integrated PHY to get rather warm and so it was interesting to note that the LM3S6965 doesn’t run hot at all. It gets only slightly warm, which is hardly noticeable in comparison to other devices like the MC9S12NE64!

The actual current consumption is not specified in the data sheet and it is difficult to measure it since the evaluation board is supplied via the USB cable. Figures will be added once such measurements have been made – either using a special USB cable or on a different board.

A final note: the LM3S6XXX Ethernet controller has been added to the uTasker simulator, allowing it to be used for projects running in the uTasker environment.

The following currents were measured using the LM3S6965 evaluation board, supplied from the 5V USB bus.
1. Board held in reset - 95mA - current consumption is assumed to be mainly for the board peripherals such as the JTAG debug interface.
2. LAN set to 10MHz fixed speed with no LAN connection - CPU running at 50MHz - 125mA
3. LAN set to 10MHz fixed speed with LAN link up - CPU running at 50MHz - 128mA
4. LAN set to 100MHz fixed speed with no LAN connection - CPU running at 50MHz - 144mA
5. LAN set to 100MHz fixed speed with LAN link up - CPU running at 50MHz - 190mA

If the reset current is removed, this gives full speed 100MHz LAN operating current of 95mA, which is very impressive indeed...!!!

252

ST^TM STM32 and STR91XF / New demo for STR9_DONGLE

« on: November 17, 2007, 06:52:54 PM »

Hi All

I have added a new demo which runs on the ST STR9_DONGLE.

If you have one and are interested in seeing what it can do, download it from:
http://www.utasker.com/software/software.html

Regards

Mark

253

Luminary Micro ^TM LM3SXXXX / LM3S6XXX watchdog

« on: November 12, 2007, 02:05:35 AM »

Hi All

Here are some details of my first experiences with the watchdog:



Watchdog

The LM3S6965 contains a watchdog timer. This is used to monitor that the system is operating correctly and can generate an NMI and system reset when it triggers. The watchdog solution is not bad since it allows the user to protect a running watchdog against run away code manipulating it. It times out twice before performing a hardware reset (if it is enabled), first with an interrupt and then after a second timeout with the reset.

When running with 50MHz system clock a watchdog timeout period of up to about 85 seconds is possible. To configure the required time, the define WATCHDOG_TIMEOUT_MS has been added to the project configuration file app_hw_lm36xxx.h. This time is the sum of the two timeout periods since the interrupt is effectively ignored.
The watchdog is also used to command a reset of the board. In this case the lock state is removed (by writing 0x1acce551 to the register WDTLOCK) and then setting a zero timeout period.

Can the watchdog stop the debugger loading to FLASH?

The first time I started working with the watchdog enabled I also started to have problems with the debugger. The debugger worked fine until I wanted to download new code, and then it couldn’t program the FLASH any more; the error was that it couldn’t download the flash loader.

I had the impression that the watchdog was still running after a reset and was possibly causing the problem because the debugger could not turn it off, although the debugger log said that it had deactivated the watchdog. I tried with a second board and the result was identical – I now had two boards which no longer accepted downloads and I started to get a bit panicky!

The solution to recover the board was to delete the FLASH by using the connected debugger (connect by suppressing download and letting the program on the board configure the PLL to 50MHz) and commanding the mass erase command. That is, write 0xa4420004 to the address 0x400fd008. The register USECR at address 0x400fe140 is set by default to 0x31 which sets the FLASH erase time to suit 50MHz clock.

After erasing the complete flash it is then necessary to power down the board (otherwise the watchdog seems to still be actively causing the problem) and then the debugger can load new code correctly.

I will be watching this and updating this section when more details are known. At least I am not so nervous any more because the recovery process is not so complicated…




Regards

Mark

254

Luminary Micro ^TM LM3SXXXX / Cortex[TM] M3 SysTick

« on: November 11, 2007, 01:32:46 AM »

Hi All

I have just integrated the uTasker system TICK using the in-built SysTick timer in the Cortex ^TM M3 core (that is what is for). Here are some more details about the work:

System TICK

The Cortex™ M3 has a timer built into the core called the system timer (SysTick). This is suitable for generating a tick for an operating system or for measuring delays. Since it is designed for generating a system TICK interrupt this is exactly what we are going to do with it. One interesting advantage of having the SysTick in the processor core (apart from the fact that it doesn’t have to be taken from a peripheral timer) is the fact that any Cortex™ M3 based processor will operate identically (apart from the actual match counter setting which will be defined by the tick period and also the system frequency) and so it is not necessary to write any more timer code to suit the next chip.
[A possible exception is when the code uses the SysTick calibration register. This register is not implemented in the Luminary Stellaris devices and so its use is avoided.]

The operation of the SysTick and various other registers belonging to the Cortex™ M3 memory range (private registers) is described in the original ARM documents rather than the chip manufacturers’ documents. This means that it is a good idea to have a collection of ARM documents and application notes – various are supplied on the Luminary Micro’s evaluation kits but all are available on the Internet as well.

I must say that the Luminary Micro documentation is really good. It is well written and proof read and presented in a quality that I haven’t seem before. Even companies like Freescale, who produce quite good documentation, could learn from Luminary. The number of errors in the Freescale data sheets is quite high – false pins and register addresses and bit names are quite frequent until the documents have been updated a few times. Also various cut-and-paste errors are common for new data sheets where it is obvious that it was correct for the older device the newer one is based on but requires some interpretation to be able to work out what it means for the new chip.

The Luminary documentation is very new and already has an incredibly good quality and accuracy. I am very impressed!
The ARM documents are certainly very detailed and probably very accurate (although it is a little more difficult to verify this) but they are all written with a style and font which gives me the feeling that I am reading open source documentation or an operating system guide from the mid-80s. My eyes tend to fall to when reading – GCC documentation tends to do the same to me. Thinking about it also the IAR documentation has a similar look. But this is going a bit off topic now. It suffices to say that I like the modern looking style plus the quality and accuracy of the Luminary documentation and it doesn’t put me to sleep, so I may well make faster progress that expected…

For a bit more detail about using the SysTick I consulted an ARM application note 179 (http://infocenter.arm.com/help/topic/com.arm.doc.dai0179b/AppsNote179.pdf).

The SysTick timer is quite interesting because it uses a reload value which is loaded to the counter when the timer is enabled. This counter counts down until it reaches zero and can generate the SysTick interrupt, when enabled. When single stepping in the debugger the counter value can be seen to also be stopped when the processor is stopped, thus it is not free running from master clock but only counts when the processor is actually also running.

If you monitor the count value from a break point at the start of a block of code and then compare the value at a break point at the end of the block of code, you can quite easily work out the execution time – as long as it is less that one tick interval it is equal to the difference in the count value and has a resolution of one clock cycle!



Comments welcome. More to follow...

Regards

Mark

255

Luminary Micro ^TM LM3SXXXX / First steps with the LM3S6965

« on: November 10, 2007, 05:34:46 PM »

Hi All

It is always exciting when you start a new project. It gives you a chance to forget the previous ones which sometimes developed into a tangled mess which you may prefer to forget. This next one will be perfect - a fresh start, a clean sheet...

Well we know what usually happens. The original euphory gets dampened by the harsh realities of the real work - pressure, deadlines to meet, software which 'should' work fine has some niggling bugs which can only be solved by all-night sessions. Is it a problem with the chip? perhaps with the compiler?...minutes, hours, days later... ooops, ehrr, that was a stupid mistake which I won't make again...

The Luminary Micro device LM3S6965 is one of these chances since it uses the new Cortex^TM M3 core and it promises to be an exciting new chip from a new company which is churning out new derivitives as fast as they can update their web site to cover them.

The chip is new to me but I spend my first short debugging session on the path to getting to know and love (or hate..?) the new family of chips which promise to open up new possibilities of embedded Ethernet capability. Support for the uTasker will only be possible after the normal learning curve but here's a taste of how it is going:


Getting Started with the LM3S6XXX

The following describes the process of getting to know and use the Luminary Micro Stellaris LM3S6965. For the exercise I bought an LM3S6965 evaluation kit and downloaded the Kick Start evaluation version of the IAR compiler Version 4.42A which includes support for the Cortex^TM-M3 processor and has various example of software controlling various peripherals.

In fact I bought an evaluation kit including KEIL software on the CD but decided against Keil due to the fact that the evaluation version limits the code size to 16k. The IAR kick start version has a 32k limit which is realistic to show demo software with a decent mix of features as necessary when working with protocols such as TCP/IP. Experience has shown that with 16k (even in Thumb mode on an ARM7) the 16k limit is just too restrictive to let anyone really experiment with useful embedded IP stuff. The Cortex^TM-M3 doesn’t have, or need, a thumb mode but code sizes equivalent to ARM7 thumb can be expected (although higher performance can be assumed).

The board in the LM3S6965 evaluation kit has a USB JTAG debugger built in to it so there is no need to use an external one. The debugger is based on the well known FTDI chip which communicates as virtual COM port. It is not the fastest method of downloading and debugging but was used to get to know the board and verify its usability.
[In addition to the LM3S6965 evaluation kit I also have two others which may be useful for comparisons. I have an LM3S1968 from the 1000 series with no Ethernet interface and an LM3S8962 with an additional CAN interface. The LP3S8962 kit comes with an LM3S2110, which doesn’t have Ethernet but does support CAN, for testing together with the LM3S8962].

Installing the IAR kick start version and the FTDI driver

You can order the evaluation board with IAR kick start software or else simply download the newest version from the IAR web site. You will need to register and then you will receive an activation key.

The software includes drivers for the FTDI chip so best get these installed as first. I installed them before installing EWARM (Embedded Workbench for ARM) by connecting the USB cable from the LM3S6965 evaluation board to a free USB port and pointing Windows to the IAR program directory (\arm\drivers\FTDI) so that it could find the driver. There is an installation guide there too which suggests getting latest drivers from the FTDI web site, which I tried following, but Windows didn’t want to be able to understand the new drivers so I simply stuck with the ones delivered with the Kick Start software. Note that there are in fact 2 or 3 different drivers required so don’t get upset when you keep getting asked to install again each time you think that it has already finished. Just keep pointing to the same driver directory and it should complete. I kept getting the message that the device was not working correctly but could still see a new COM port in the device manager (open system control, then system/hardware and then device manager and expand the COM port group) called “Stellaris Virtual COM port" – COM4 in my case on my WinXP PC).

I opened a workspace example in the IAR program directory (\arm\examples\Luminary\LM3SXXX\dk-lm3Sxxx.eww) and compiled the gpio_led demo project. This compiled with no errors and afterwards I could download the code to FLASH (the set up in the project is for FLASH download) by pressing on the debug button.

As I said previously, it is not the fastest debugger and stepping through code requires a little patience but it does work otherwise fine, so there was nothing to stop me getting down to doing some real work.

Start up code

Any one familiar with working with ARM7 or ARM 9 etc. may be a little surprised that if you remove the debugger setting “Run to main” – which is useful to see what is happening on start up – it doesn’t actually make any difference: the first executed code is the first line of main!

I was at a Luminary Cortex^TM-M3 seminar a while back and this was one of the things that was repeatedly stated as being a big plus. “No assembly code required—ever!”. The majority of discussions in the seminar still worked with assembler code… but let’s take a look at what the big deal is here.

The first thing to remember is that the Cortex^TM-M3 processor is a new version of the ARM processor and it has a number of changes. The original ARM architecture has been very successful but does have a few basic problems or weaknesses which have been improved on, with the result that the Cortex™-M3 is easier to use, faster and uses less code space to achieve higher performance. Major improvements have been achieved by adding a vectored interrupt controller with guarantied interrupt latency (faster than any previous ARM) which also supports up to 240 prioritised interrupts and nesting. This means that the chip manufacturers no longer have to bolt on their own interrupt controller since it is included in the core – this will probably make it easier to move between Cortex^TM-M3 processor types since the interrupt controller is now also standardised.

The Cortex^TM-M3 has a different vector table (as well as different internal registers) – remember this is not an ARM as you may already be used to. The vector table looks like a Motorola (Freescale) vector table, with the first long word being the value which is loaded to the stack pointer and the second long word being the start address. As long as the code can ensure that the pointer to the top of stack can be forced to reside at address 0x00000000 and a pointer to the routine main is forced to reside at address 0x00000008 then the routine main() is the first instruction which will be executed. Since the Cortex^TM-M3 supports what is known as the Thumb-2 instruction set, which never needs to swap between Thumb and ARM, nothing else is required to start working.

I don’t exactly see the difference to the architecture that Motorola has been using since the beginning of time and I assume that if Freescale marketing had been clever, it could also have pointed out that theoretically it never needs any assembler code to operate...we will see whether there are other big differences as work progresses!!

The first demo code which runs doesn’t use any interrupts (as is typical of demo code) and I realise that it doesn’t actually do anything visible on the board which I am using but the debugger operates correctly and it illustrates setting up the PLL and configuring some ports so it may prove a useful reference if things don’t start as expected in the main project.


To be continued...


Comments welcome, as normal.

Regards

Mark