Author Topic: SPI in the simulator  (Read 10350 times)

Offline ewan

  • Newbie
  • *
  • Posts: 43
    • View Profile
SPI in the simulator
« on: March 07, 2008, 02:15:53 AM »
I am using the M52233DEMO board configuration in VS 6.0 and was trying to simulate an SPI chip. I have the latest download with SP6 installed including renaming the "config_ref_m5223X_sp6.h" file to "config.h".

I used the "Configuration example" in the "uFileSystem in SPI FLASH" application note. The symptom is that while I get the correct 1MByte file with some stuff in it, it is incorrect. For example I have 10 files named E.htm to N.htm with sizes from 32KBytes to 138KBytes for a total of 621KBytes. Using IE v6.0.2800 I contact the device using ftp. I then drag and drop the files to the ftp window. All seems well. The IE window shows all the files. When I press "F5" to refresh, however, there are typically only two files there. Upon inspection, the AT45DBXXX.ini file is mostly populated with 0xff bytes.

Any clues?

Thanks,

Ewan.

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: SPI in the simulator
« Reply #1 on: March 07, 2008, 12:54:40 PM »
Ewan

If you take the reference settings the File granularity is set up for 16k blocks. This means that if you save a file of 128k size it will occupy 8 file blocks.

If you name the file E..N you are specifying the use of 10 file blocks and so 10 files of up to 16k each would be possible.
It is possible to write, for example, a file E.html of 128k (it will occupy 8 blocks) but this means that the next file must be named M.

What is happening is that if you first write the 128k file E.html it will be correctly saved. Then writing a 16k file called F.html will 'bulldoze' space to be able to fit. It will infact have to first erase and file occupying its destination - which would mean first erasing the complete file E.html.

The underlying principles are described in http://www.utasker.com/docs/uTasker/uTaskerFileSystem.PDF
The document http://www.utasker.com/docs/uTasker/uTaskerFileSystemSPI_FLASH_002.PDF describes the extension for SPi FLASH but the basics remain the same.

This means that the file use is in fact a part of the design process since there are some restrictions (the advantage is that it is very code efficient). Also take a look at the documents in \Applications\uTaskerV1.3\WebPages\WebPagesxxxx\FileSystem\
Here is areference as to how the file content can be managed.

Regards

Mark

Offline ewan

  • Newbie
  • *
  • Posts: 43
    • View Profile
Re: SPI in the simulator
« Reply #2 on: March 07, 2008, 07:56:16 PM »
Mark,

I got it all to work. There is a lot of documentation.

Thanks,

Ewan.

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: SPI in the simulator
« Reply #3 on: March 07, 2008, 08:32:12 PM »
Ewan

Great.

The SPI FLASH interface has proven to be quite popular. The uFileSystem is a bit special but it is however well suited to most embedded projects with the smallish single-chip processors which it specialises in. It has proven very reliable and the simulator very accurate, making work on the HW hardly necessary. We will introduce a driver soon for the ST SPI FLASH chips (also quite popular).

The only word of warning when using these devices (valid for both ATMEL and ST SPI FLASH chips) is that they can be very sensitive to overshoot and ringing on the signal lines (especially the CLK line) - the SPI lines should be as short as possible in hardware designs and it is can also be a good idea to have termination on the CLK line to match the track impedance and stop reflections.

The older ATMEL B-type chips are much less sensitive but the newer D-type ones can have reading errors as soon as a scope of a logic analyser is connected to its CLK!!

Last point: the delete time of the newer D-type chips is quite a bit longer than the older B-type ones. I thought that the newer ones would get faster but this doesn't seem to be the case with SPI FLASH delete times - a little surprising. I wonder what the reason is...

Regards

Mark

Offline danh

  • Newbie
  • *
  • Posts: 28
    • View Profile
Re: SPI in the simulator
« Reply #4 on: April 14, 2008, 07:07:22 PM »
Hi Mark,

You mentioned upcoming support for ST SPI FLASH chips. I presume that will include M25P80. Any idea on when that will be available?

Thanks,

Dan

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: SPI in the simulator
« Reply #5 on: April 14, 2008, 07:45:42 PM »
Hi Dan

The support is for 4MBit..64MBit (M25P and M25PE types).
This has been released (although not fully tested...) in the latest LPC23XX SP.
It is also ready in the Luminary and M5223X SPs (which have still to be released).

Which processor do you need it for and when will you need it?

Regards

Mark

Offline danh

  • Newbie
  • *
  • Posts: 28
    • View Profile
Re: SPI in the simulator
« Reply #6 on: April 14, 2008, 08:56:15 PM »
Mark,

We are using the M52235 processor. I need it... well... now, actually. But I am porting over code from another project for the time being. I am not even trying to integrate it so that the SPI flash file system will work, but we do want that feature fairly soon.

BTW, I am evaluating uTasker by writing a little self-test build for our board using it. I'm pretty sure we will decide shortly to go ahead with it for our project, so you'll be hearing from us on a license purchase soon.

Thanks,

Dan

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: SPI in the simulator
« Reply #7 on: April 14, 2008, 10:21:22 PM »
Hi Dan

We have been testing on the M5223X with 4 x 64MBit M25Ps (32MByte) to store speech recordings which are downloaded as WAV files (or opened in browser) - therefore the support is working well.

If you decide to go with a uTasker license just shout and I can get you the drivers right away. In any case, I hope to get a new Coldfire SP available quite shortly including this and some other interesting new stuff...

Regards

Mark

PS. If you are simulating your project you can immediately set it up to use the ATMEL device - to move to the ST involves setting just one define, so it is very easy to swap between the two.