Author Topic: 4th Generation of Stellaris = Tempest Class (2009)  (Read 10304 times)

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
4th Generation of Stellaris = Tempest Class (2009)
« on: March 07, 2009, 01:40:40 AM »
Hi All

In case you missed it, Luminary Micro announced their 4th generation "Tempest Class" Stellaris at the Embedded World in Germany.

•   Higher performance with lower operating power (up to 80 MHz, 1.2v internal supplies)
•   Powerful external interface for high-speed chip-to-chip interconnect
•   Enhanced subsystems including dual ADCs, extended in-ROM software, precision oscillator, and I2S interface
•   Expanded networking and connectivity with Ethernet, CAN and USB options and combinations
•   Expanded SRAM and augmented UART support

Take a look at the LM3S9B95:
http://www.luminarymicro.com/products/LM3S9B95.html

100MHz operation, 2 x CAN, 3 x UART, 2 x I2C, 16 x 10bit ADC, 256k FLASH, 96k SRAM, USB-ORT, Ethernet MAC + PHY with IEEE1588 support, I2S and various other stuff in a 100 pin LQFP package.

It should be available in Q2 2009.

I just read some of the user manual - it's quite frightening. Pins have up to 11 peripheral functions each!

Regards

Mark
« Last Edit: March 09, 2009, 12:55:04 AM by mark »

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: 4th Generation of Stellaris = Tempest Class (2009)
« Reply #1 on: December 06, 2009, 09:03:15 PM »
Hi All

Here is an update on the state of support for the LM3S9BXX.

Although the Tempest devices were added to the project some time ago, this was only based on the simulator. The reason being that the devices were still very hard to get hold of.

In the mean time there have been some silicon revisions, the most up to date being revision C. My LM3S9B90 demo board has a revision B1 chip on it which still has a number of restrictions, whereby it is advised to carefully study the errata when starting with the chips. If you are lucky enough to start with the revision C then most workarounds have become redundant.ul.

After (finally) completing the verification of the standard project running on this board here are my notes about changes.

- the main known changes were to the multiplexing of the ports and this was all fully prepared. However the chip had to be fully added to the simulator.

- the chip on my board can run at up to 80Mz. However it was initially running at 66.666MHz rather than the expected 80MHz. I found the reason for this to be due to extended functionality in the RCC2 register to allow increased frequency control and just working with the RCC was not allowing 80MHz (best it could do was 66.666MHz). It took quite some time to sort this out because the order of setting bits is critical but I managed to get the code so the user can simply enter the required frequency and the start-up does the rest (either using the standard solution if possible or switching to the extended solution where necessary).

- The PHY used in the newer chips is a bit different. It even has a different OUI... some registers have different functionality so a modification was necessary in the PHY initialisation and also PHY interrupt handler.

- FLASH was being written but not reliably. After studying the manual and errata, plus some debugging, three critical differences were identified:
a) The FLASH sectors - each 1k in size - are grouped into electrical blocks of 4k. If 6 write/erase cycles are performed within such a block, other sectors within that block need to be "refreshed" so that they don't lose data. This is rather tricky to manage (especially counting accesses over power-cycles...), so the file granularity of the project was modified to be equal to 4k, which ensures that files are always built out of 4 x 1k sectors. Since files are written and deleted as a complete unit the electrical restriction no longer affects it. The uFileSystem in FLASH should however always begin on a 4k boundary too! File granularities of anything than 4k, 8k, 12k etc. are to be avoided!!!
The same goes for the uParameterSystem, if used. This should also begin on a 4k boundary and each parameter block of a size equal to 4k or a multiple of it.

b) The steps in a) didn't resolve all difficulties so the processor clock speed was set to 50MHz rather than the 80MHz which the processor on the development board can achieve. This is due to an errata (solved in the C-silicon) where FLASH writes are stated as not being successful above 50MHz. In this case I am not absolutely sure whether the used method is affected or whether it is only an issue when using the new FLASH buffer write feature (new in the Tempest parts). However to be on the safe side I keep to 50MHz.

Note also that there is a limit to the FLASH data retention when a lot of page erases take place, which can cause data loss. This should not be an issue in most uses of the uFileSystem - only becoming noticeable when 3'000 and more page erases take place without a mass erase. It is also fixed in the latest C-revision. Clearly starting with C-chips in a new project will avoid possible pit-falls.

c) Practical tests showed that the Tempest parts no longer support cumulative writes to a single long word FLASH address. To avoid this, the uParameterSystem driver interface (for Luminary) and also the general FLASH write driver (for Luminary) needed to to be adapted. The FLASH driver interface (when used with Tempest parts) uses an additional small buffer to hold data until a complete long word has been collected - only then will it be committed. The same technique is used in other flash drivers (eg. LPC2XXX and AVR32) so is nothing really new. Without it data corruption was taking place when writing files. The setting to control this is fixed in LM3SXXXX.h with FLASH_LINE_SIZE set to 8 (used by the uFileSystem interface) and FLASH_ROW_SIZE set to 4 (bytes), to ensure that this is the smallest write size.
The only side effect of this is that each parameter in the uParameterSystem requires a complete long word of physical space. A 4k parameter block (see a) ) can thus hold up to 1022 bytes of parameter data.

For an overview of the FLASH characteristics see also the Luminary forum: http://www.luminarymicro.com/component/option,com_joomlaboard/Itemid,92/func,view/id,7594/catid,5/

Assuming no additional problems the latest LM3S9BXX support will be released shortly. Beta tests just email me...;-)

Regards

Mark