Where is the SPI clock speed defined at ?

[seulater]

I just wire wrapped the SST part onto my olimex board. Before doing this i got the message that it was not found, which is good. Now i dont get that and i can see on the oscilloscope that indeed the CS, MOSI, MISO and clk signals are there. But it not continuing to boot.
it seems to keep trying the CS line every 6 seconds.

I would like to kick the clk speed down to see if that helps.

[seulater]

Found it. For anyone interested it in the driver.h file.

[mark]

Hi

The configuration is in fnConfigSPIFileSystem() but this generally only supports 2M and max SPI speed for the processor.

However I am not sure about the SPI FLASH type. The LPC23XX project includes ATMEL and ST support and not SST. Which processor are you running this on?

Regards

Mark

[seulater]

i am using the LPC2378, on the Olimex LPC2378STK.
i am getting confused because there is a #define SPI_FLASH_SST25 in config.h, however when i go to ap_hp_lpc23xx.h there is not this particular type defined there.


Also, when reading the uTaskerSPI_EEPROM.pdf it says the following.
"Comment in the define SPI_FILE_SYSTEM and comment out the define
FLASH_FILE_SYSTEM. The FLASH based file system will be shut out and the SPI EEPROM
based version will be used instead."

Mine looks like this now:

Code: [Select]

  #define SPI_FILE_SYSTEM                                              // we have an external file system via SPI interface
   // #define FLASH_FILE_SYSTEM                                            // we have an internal file system in FLASH
  //#define NVRAM                                                        // we have an external file system in non-volatile RAM
    #define INTERNAL_USER_FILES                                          // allow user to specify program file content
        #define EMBEDDED_USER_FILES                                      // use together with INTERNAL_USER_FILES to allow sending an embedded user file to the uFileSystem
#endif

when i do this, i get an compiler error saying "'uFILE_START' undeclared (first use in this function)" in the file ftp.c

[mark]

Hi

First of all there seems to be a confusion between SPI EEPROM and SPI FLASH.

The SPI EEPROM has essentially been replaced by SPI FLASH and so is probably never used anymore. This means that the configuration is

SPI_FILE_SYSTEM and FLASH_FILE_SYSTEM

The document to follow is: http://www.utasker.com/docs/uTasker/uTaskerFileSystemSPI_FLASH_003.PDF


The problem with the LPC23XX project is that it doesn't include SST SPI FLASH support (just ATMEL and ST). This is in fact not a big deal to add but hasn't been done so yet.

I will send you the equivalent files from a package with SST support. Essentially you need to add the file spi_flash_lpc_stt25.h at several locations in LPC23XX.c

Eg.
            #include "spi_flash_lpc_atmel.h"
            #include "spi_flash_lpc_stmicro.h"
            #include "spi_flash_lpc_stt25.h"

and then make a few adjustments in the FLASH access routines to use the appropriate commands as well as possibly adjusting the low level SPI driver access.

Since the ATMEL driver is very similar I am sending you the files SAM7X.c and spi_flash_sam7x_sst25.h as reference.
The SST devices are included in the simulator and so it should also be possible to prove that the changes are correct.

If you prefer not to do this work yourself (it may turn out to be easy but there may also be some difficulties to be overcome) I can try to get the two files adapted so that you just need to do end testing (seeing as you have a board wired up already ;-)

Regards

Mark

[jezc]

Hi Mark,

I'd be very interested in the outcome of this as we have both Atmel 32MBit & SST 64 MBit SPI Flash connected to one SPI/SSP port of the LPC2478 on our design.

We're using the same port for both devices but using different GPIO lines to act as the chip selects for the two devices.

Basically, we're using the Atmel as NVRAM (as the erase & write sector size is the same) and the SST will be used as an off-chip file-store.

No desperate rush for this at present - I'd just like to know if/when it works. We're probably a couple of months away from needing the functionality at least.

Cheers,
    Jez

[mark]

Hi Jez

The SPI FLASH interface supports several SPI FLASH devices controlled automatically by individual CS lines (up to 4 in most cases - at least this many are supported in the simulator). This is solved by defining the SPI FLASH area as an area in the memory map - this is virtual since there is not physical address involves as in the case of parallel memory. The mapping allows the chips to be selected (CS line) and then the address location inside the selected chip.

However the interface assumes that all of the SPI FLASH chips are the same (same family type and same size).

This means that mixing 2 different chips will not work automatically since each chip needs its own interface driver. Probably the easiest technique would be to add the driver type decision using the same memory mapping principle; first selecting the chip and then the driver to be used for the access. Not difficult but will need to be done...and also needs a driver for each type.

Regards

Mark

[mark]

Hi

I have added the SST SPI Flash to the LPC23XX and LPC17XX projects. I tested a SPI_FLASH_SST25VF016B on an MCB2300 to verify that it worked.
In fact I re-wrote the driver to utilise the LPC23XX's 8 deep SPI FIFO (although there is in fact no real advantage of using the FIFO in this application - more as reference) and it worked first time on the HW so that went well. The LPC17XX version uses the same driver and so I just tested its configuration in the simulator. The following small packs include the new code (I can't be absolutely sure that it will just drop in but the changes should be quite clear), including a configuration for the SPI chip (note that SPI_FILE_SYSTEM may have to be set since I think that I removed it during some follow up tests as described below):

http://www.uTasker.com/software/V1.4/LPC23XX_SST25.zip (passwords from V1.4 project)
http://www.uTasker.com/software/V1.4/LPC17XX_SST25.zip

Although things did indeed work first go I realised that the GCC stand-alone build was sometimes hanging when serving pages from SPI FLASH on the web server. However other builds were stable (including Rowley, which also uses GCC and the same files).

After a few unsuccessful attempts to solve this (it was hanging when the SPI FLASH chip select line was held low so seemingly obviously in the new driver part) I realised that it was in fact the same when serving the pages from internal FLASH. Then looking at my "to do list" I also realised that this is a known issue with this build - unfortunately after a few hours I still hadn't got any closer to solving it - just verifying that it is there and not in any other projects... Finally I concluded that, since this has nothing to do with the new SST driver (although it does almost always hang when retrieving data from the FLASH - supposedly since this is the main activity at the time) there was no reason not to post it.

I would certainly be interested in other peoples experiences with the GCC build (maybe it is restricted to the version that I am using - gcc version 4.2.3 (Sourcery G++ Lite 2008q1-126) ?) but the fact is that the instability is during serving web pages and the picture that I get in the debugger is not really helping much. It is (seemingly?) indicating a data or program abort occurs when it handles a normal interrupt - it looks as though it is getting interrupted, jumping to the IRQ (address 0x18) and then immediately jumping from there into the abort handler. I am not absolutely sure but it is something that I really cant explain - also why it works fine compiled by the GNU compiler as used by Rowley... Going a bit off-topic but it would be nice to get to the bottom of this one!

Regards

Mark

[mark]

Hi All

Note that the GCC instability problem has been identified and solved as explained here:

http://www.utasker.com/forum/index.php?topic=871.0

Regards

Mark

[mark]

Hi All

This is an update to the SPI FLASH support in the LPC17XXBeta package.

1) So that the Beta version compiles, remove the following defines from app_hw_lpc17xx.h:

#define SUPPORT_TIMER
#define SUPPORT_EXTERNAL_INTERRUPTS
and
#define SUPPORT_PORT_INTERRUPTS


2) In config.h enable SPI_FILE_SYSTEM to get the uFileSystem running in the SST chip (rather than in internal FLASH). Also ensure that there is no SD card in the slot otherwise the web server will try prefer to use it instead.

3) Use the following set of web pages to test the web server from SPI FLASH:
http://www.uTasker.com/software/V1.4/LPC17XX_WebPagesSPI.zip
(these suit the SPI FLASH since the original ones suit internal FLASH and are not compatible).

Regards

Mark

[seulater]

I have just installed my SPI Flash on the Olimex LPC1766-STK board. I am using the UXT header on the board. For the ~CS line i will use pin 10 (CS_UEXT) which is P1.26 on the uP.
I have verified with scope that i am getting SCK1 and MOSI, but no CS.
I have changed app_hw_lpc17xx.h to this for the CS line change.
#define CS0_LINE            PORT1_BIT26
#define CS_SET_PORT         FIO1SET
#define CS_CLR_PORT         FIO1CLR
#define SPI_CS0_PORT        FIO1PIN

but there is still no activity on p1.26 is there something else i missed ?

[mark]

Hi

I expect that the configuration of the CS is missing.

    #define CONFIGURE_CS_LINES()        FIO0SET = CS0_LINE; FIO0DIR |= CS0_LINE; _SIM_PORTS

As you see this is assuming the CS0_LINE to be on port 0.
Since you have it on port 1 instead this will also need to be adjusted:

    #define CONFIGURE_CS_LINES()        FIO1SET = CS0_LINE; FIO1DIR |= CS0_LINE; _SIM_PORTS

It helps to check configurations in the simulator since it is quite easy to check whether the pin is is configured as expected.
However when I run mine I see that the project code is in fact setting P1-26 as an output '1' in fnInitialisePorts() in debug.c. It is also blinking P1-25 at the watchdog rate. Possibly you already changed that (eg., comment out fnInitialisePorts() so that the demo doesn't configure any ports unexpectedly).

Regards

Mark

[seulater]

I missed that line, changed it and it recognized the SPI. Thanks.