LPC2366 Flash size wrong

[aaronlawrence]

Hi,

Just moved the LPC demo project (CrossWorks) over to our board with an LPC2366 and it dies immediately. Found that it's trying to access Flash at 7C000 (496k) which doesn't exist on LPC2366.
Questions:
1) What do I do to correct it? The code seems to be written assuming only 21xx is different, but there are many differences in the different models.
2) How many more of these nasty surprises will I have? Is the support really only tested for LPC2368?

Thanks.
Aaron

[mark]

Hi Aaron

The LPC23XX project has configurations for the OLIMEX LPC2378-STK and the Keil MCB2300, which both have the LPC2378 on them with 512k FLASH and 58k SRAM.
Since you are using a different board to these, with different processor you may need to configure your board appropriately: setting the LPC2366FBD100 processor in config.h basically informs the project that this device, with 256k FLASH and 56k RAM is being used, but this is only one detail for the project - the FLASH file system will still be configured for the board (eg. OLIMEX_LPC2378_STK) which will try to use the non-existing FLASH area.

To solve this do the following:
1) In config.h configure your own board type, eg.
#defined MY_BOARD_WITH_LPC2366
        #if defined MY_BOARD_WITH_LPC2366
            #define TARGET_HW       "LPC2366 board"
        #elif ...

2) You can also make this board conditional on the define LPC2366FBD100 so that switches between your board and a development board can be automated by the processor type.

3) Now do a search for an existing configuration in the hardware configuration file app_hw_lpc23xx.h, eg. search for OLIMEX_LPC2378_STK. You will find that there are about three locations in this file where there are conditional configurations on the board type:
a) where ports are configured (eg. the blink LED and some user ports) - you may like to add another board setup to adjust these to appropriate ports for your own board, or set some to dummy defines if not of interest. If you find that an existing configuration already matches (is suitable) then use it by setting
#if defined OLIMEX_LPC2378_STK || defined MY_BOARD_WITH_LPC2366
b) where this PHY is defined. The Olimex uses the MICREL KS8721 and the Keil MCB2300 used the NATIONAL DP83848, whereby there is also a third configuration for the SMSC LAN8700. If you have one of these you can add your board's define to the section as appropriate; check that all details are correct because you may have a different PHY address or other slight differences. In the worst case you may have a different PHY which hasn't been used before. In this case you may need to add a new HW setup...

4) The file system configuration setup has no board defines - this looks something like this:

        #ifdef _LPC21XX
            #define uFILE_START (FLASH_START_ADDRESS + FLASH_SECTOR_11_OFFSET)// FLASH location at 88k start
            #define SUB_FILE_SIZE    (FILE_GRANULARITY / 4)              // 2k sub file sizes
            #define SINGLE_FILE_SIZE (1*FLASH_GRANULARITY_LARGE)         // each file a multiple of 8k
            #define FILE_SYSTEM_SIZE (4*FLASH_GRANULARITY_LARGE)         // 32k reserved for file system
        #elif defined _LPC24XX || defined _336K_FILE_SYSTEM_SPACE
            #define uFILE_START (FLASH_START_ADDRESS + FLASH_SECTOR_12_OFFSET)// FLASH location at 160k start
            #define SUB_FILE_SIZE    (FILE_GRANULARITY / 8 )              // 4k sub file sizes
            #define SINGLE_FILE_SIZE (1*FLASH_GRANULARITY_LARGE)         // each file a multiple of 32k
            #define FILE_SYSTEM_SIZE ((10*FLASH_GRANULARITY_LARGE) + (4*FLASH_GRANULARITY_SMALL)) // 336k reserved for file system
        #else
            #define uFILE_START (FLASH_START_ADDRESS + FLASH_SECTOR_12_OFFSET)// FLASH location at 160k start
            #define SUB_FILE_SIZE    (FILE_GRANULARITY / 8 )              // 4k sub file sizes
            #define SINGLE_FILE_SIZE (1*FLASH_GRANULARITY_LARGE)         // each file a multiple of 32k
            #define FILE_SYSTEM_SIZE ((5*FLASH_GRANULARITY_LARGE) + (4*FLASH_GRANULARITY_SMALL)) // 176k reserved for file system
        #endif

This is probably where your main problem is coming from. You can create your personal board setup by adding your board here, or it may also be adequate in your case to ensure that the board setup in config.h doesn't select the _336K_FILE_SYSTEM_SPACE: if you look at the OLIMEX_LPC2378_STK configuration there it is specially setting a file system to utilise the complete FLASH area (512k in that case) to demonstrate firmware upload capabilities. In the case of the KEIL_MCB2300 this define is not being set and so it actually is already suitable for the 256k FLASH part.

5) Finally: Since your chip has the same SRAM configuration this should already be adequate. However note that in some cases the linker script file for the target compiler may need to be adjusted. It is not always practical to have linker script files for every possible device, and also targets for each in every compiler so usually the standard development board setups are included. To adjust these to particular processor usually requires the SRAM size to be set accordingly (possible the appropriate linker script configured to the target). This needs to be checked but is usually not a big problem - unfortunately automating things link linker scripts (and some times also assembler start up files) is not possible since this is something which every compiler (or IDE) manufacturer does differently and usually has no provision for it anyway...).

Regards

Mark

[aaronlawrence]

My problem is that fnGetValidPars uses PARAMETER_BLOCK_1 which is defined as PARAMETER_BLOCK_START. which is simply defined as
        #define PARAMETER_BLOCK_START   FLASH_SECTOR_26_OFFSET           // 496k
(except for LPC21xx)
so it always puts the configuration at 496k. Thats the part that doesn't work.
It's not obvious what the alternative layout is when using only 256k.
Since I don't see any diagrams of how the memory is used I can't speculate where it is safe to put

[aaronlawrence]

Hm, there are further hard coded references to sectors assuming 512k, e.g. in
fnGetFlashSector(unsigned long FlashAddress) it refers to FLASH_SECTOR_22_OFFSET

Looks like there is substantial rework to be done here to make the file system and parameters work in 256k or 128k.....

I think I will disable the whole thing and do something myself - I don't need a web server or file system for the end product, just using this to get a demo going as easily as possible.

[mark]

Hi

Sorry, I missed the parameter block setting.

There are two memory maps which can be used as reference: in LPC23XX.c

Code: [Select]

    #define FLASH_START_ADDRESS              0                           // up to 512k
    #define START_OF_FLASH                   FLASH_START_ADDRESS
    #define RAM_START_ADDRESS                0x40000000                  // up to 64k
    #define ETHERNET_RAM_START_ADDRESS       0x7fe00000                  // 16k
    #define ETHERNET_RAM_SIZE                (16 * 1024)
    #define USB_RAM_START                    0x7fd00000                  // 8k
    #define USB_RAM_SIZE                     (8 * 1024)

    #define FLASH_GRANULARITY_SMALL          (4*1024)                    // small blocks
    #define FLASH_GRANULARITY_LARGE          (32*1024)                   // large blocks

    #define FLASH_SECTOR_0_OFFSET            0
    #define FLASH_SECTOR_SIZE_0              FLASH_GRANULARITY_SMALL     // initially small blocks
    #define FLASH_SECTOR_1_OFFSET            0x1000
    #define FLASH_SECTOR_SIZE_1              FLASH_GRANULARITY_SMALL
    #define FLASH_SECTOR_2_OFFSET            0x2000
    #define FLASH_SECTOR_SIZE_2              FLASH_GRANULARITY_SMALL
    #define FLASH_SECTOR_3_OFFSET            0x3000
    #define FLASH_SECTOR_SIZE_3              FLASH_GRANULARITY_SMALL
    #define FLASH_SECTOR_4_OFFSET            0x4000
    #define FLASH_SECTOR_SIZE_4              FLASH_GRANULARITY_SMALL
    #define FLASH_SECTOR_5_OFFSET            0x5000
    #define FLASH_SECTOR_SIZE_5              FLASH_GRANULARITY_SMALL
    #define FLASH_SECTOR_6_OFFSET            0x6000
    #define FLASH_SECTOR_SIZE_6              FLASH_GRANULARITY_SMALL
    #define FLASH_SECTOR_7_OFFSET            0x7000
    #define FLASH_SECTOR_SIZE_7              FLASH_GRANULARITY_SMALL
    #define FLASH_SECTOR_8_OFFSET            0x8000                      // end large blocks

    #define FLASH_SECTOR_SIZE_8              FLASH_GRANULARITY_LARGE     // last sector in 64k part
    #define FLASH_SECTOR_9_OFFSET            0x10000
    #define FLASH_SECTOR_SIZE_9              FLASH_GRANULARITY_LARGE
    #define FLASH_SECTOR_10_OFFSET           0x18000
    #define FLASH_SECTOR_SIZE_10             FLASH_GRANULARITY_LARGE     // last sector in 128k part
    #define FLASH_SECTOR_11_OFFSET           0x20000
    #define FLASH_SECTOR_SIZE_11             FLASH_GRANULARITY_LARGE
    #define FLASH_SECTOR_12_OFFSET           0x28000
    #define FLASH_SECTOR_SIZE_12             FLASH_GRANULARITY_LARGE
    #define FLASH_SECTOR_13_OFFSET           0x30000
    #define FLASH_SECTOR_SIZE_13             FLASH_GRANULARITY_LARGE
    #define FLASH_SECTOR_14_OFFSET           0x38000
    #define FLASH_SECTOR_SIZE_14             FLASH_GRANULARITY_LARGE     // last sector in 256k part
    #define FLASH_SECTOR_15_OFFSET           0x40000
    #define FLASH_SECTOR_SIZE_15             FLASH_GRANULARITY_LARGE
    #define FLASH_SECTOR_16_OFFSET           0x48000
    #define FLASH_SECTOR_SIZE_16             FLASH_GRANULARITY_LARGE
    #define FLASH_SECTOR_17_OFFSET           0x50000
    #define FLASH_SECTOR_SIZE_17             FLASH_GRANULARITY_LARGE
    #define FLASH_SECTOR_18_OFFSET           0x58000
    #define FLASH_SECTOR_SIZE_18             FLASH_GRANULARITY_LARGE
    #define FLASH_SECTOR_19_OFFSET           0x60000
    #define FLASH_SECTOR_SIZE_19             FLASH_GRANULARITY_LARGE
    #define FLASH_SECTOR_20_OFFSET           0x68000
    #define FLASH_SECTOR_SIZE_20             FLASH_GRANULARITY_LARGE
    #define FLASH_SECTOR_21_OFFSET           0x70000
    #define FLASH_SECTOR_SIZE_21             FLASH_GRANULARITY_LARGE

    #define FLASH_SECTOR_22_OFFSET           0x78000                     // further small blocks
    #define FLASH_SECTOR_SIZE_22             FLASH_GRANULARITY_SMALL
    #define FLASH_SECTOR_23_OFFSET           0x79000
    #define FLASH_SECTOR_SIZE_23             FLASH_GRANULARITY_SMALL
    #define FLASH_SECTOR_24_OFFSET           0x7a000
    #define FLASH_SECTOR_SIZE_24             FLASH_GRANULARITY_SMALL
    #define FLASH_SECTOR_25_OFFSET           0x7b000
    #define FLASH_SECTOR_SIZE_25             FLASH_GRANULARITY_SMALL
    #define FLASH_SECTOR_26_OFFSET           0x7c000
    #define FLASH_SECTOR_SIZE_26             FLASH_GRANULARITY_SMALL
    #define FLASH_SECTOR_27_OFFSET           0x7d000
    #define FLASH_SECTOR_SIZE_27             FLASH_GRANULARITY_SMALL     // last sector in 512k part - last 8k are occupied by ISP routines
#
and in the documents about the file system layout in \Applications\uTaskerV1.4\WebPages\WebPagesLPC23xx

The header is however probably the easiest overview of where the FLASH blocks are in the different chips.

For a 256k chip it can be set to
        #define PARAMETER_BLOCK_START   FLASH_SECTOR_13_OFFSET
to position the parameter block start to two sectors before the end of the internal FLASH - 192k.
This is however not a small (4k) block but a large (32k) block, which also requires
#define PARAMETER_BLOCK_GRANULARITY     FLASH_GRANULARITY_LARGE


However again (unfortunately) there is a complication due to the LPC2XXX family which needs to be discussed. This is indeed not always the easiest FLASH to work with due to several reasons:
1) it has quite a large FLASH granularity of 32k (the file system usually uses large-granularity mode as described in the documents in the directory above)
2) the FLASH granularity is not constant and also device dependent. There are 8 x 4k sectors at the start of FLASH and the 512k device also has 6 x 4k sectors at the end. The smaller sectors are more suitable for use as parameter blocks (that is why they are positioned there in the existing board setups), but your chip doesn't have the 4k there so will be using large sectors - probably not that efficient.
What you can do is define to use small blocks at the start but in this case there is more work (possibly compiler specific too) because the linker script will need to be manipulated to that these blocks are left free of any code... possibly there are also more difficulties involved in this case to to the fact that downloading code may cause these sectors to be overwritten by the downloading program (depending on how intelligent it is)...

Note that, if the bare-minimum boot loader configuration is used this can also resolve any potential difficulties of positioning the parameter blocks at the start of memory. The boot loader occupies the first small sector so by linking the application just after the parameter block area rather than right after the boot block sector (plus change the boot load application start address to suit) there will automatically be a space between the boot loader code and the application code for use by the parameter blocks.

If you prefer to you can also remove the parameter system by commenting out USE_PARAMETER_BLOCK in config.h. In this case the fixed default parameter values will always be used and can not be changed but you won't need to worry about the internal FLASH workings for a demo.

3) See http://www.utasker.com/forum/index.php?topic=136.0 for more background details about the FLASh technology used in the LPC2XXX family, including a link to a Philips Apps note giving otherwise generally undisclosed internal details - this was very useful when starting with the original LPC2106 back in 2004.



FLASH_SECTOR_22_OFFSET

I see no problems with the routine using the FLASH_SECTOR_22_OFFSET since this is a generic routine used by the FLASH driver to work out which FLASH sector an address is in. This is the cut off sector between the large blocks and the final small blocks. If you are using a smaller chip it will never get to this comparison (it is an address reference and not an address access so can not fail):

Code: [Select]

static unsigned long fnGetFlashSector(unsigned long FlashAddress)
{
    FlashAddress -= FLASH_START_ADDRESS;
    if (FlashAddress < FLASH_SECTOR_8_OFFSET) {                          // one of the first small sectors
        return (FlashAddress/FLASH_GRANULARITY_SMALL);
    }
    else if (FlashAddress < FLASH_SECTOR_22_OFFSET) {                    // one of the middle large sectors
        FlashAddress -= FLASH_SECTOR_8_OFFSET;
        return ((FlashAddress/FLASH_GRANULARITY_LARGE) + 8);
    }
    else {                                                               // one of the last small sectors
        FlashAddress -= FLASH_SECTOR_22_OFFSET;
        return ((FlashAddress/FLASH_GRANULARITY_SMALL) + 22);
    }
}
It would be possible to remove the last comparison by making the final check conditional on the chip size

#if SIZE_OF_FLASH > (254*1024)
    else {                                                               // one of the last small sectors
        FlashAddress -= FLASH_SECTOR_22_OFFSET;
        return ((FlashAddress/FLASH_GRANULARITY_SMALL) + 22);
    }
#else
    return 0;                                                           // error - access outside of FLASH area
#endif

but there is no real advantage since an attempted access outside of the FLASH area is incorrect in both cases...


You can completely remove the uFileSystem by disabling FLASH_FILE_SYSTEM in config.h. Since the FTP requires this you will have to disable it too. However I don't think that there is any real reason to do this - the parameter system define has nothing to do with the file system and the file system can live without the parameter system if you don't want to get involved with the best parameter system configuration. Note also that the web server can run from embedded file - rather than files situated in the uFileSystem so a web server based application can also exist without any file system, - this is described here: http://www.utasker.com/docs/uTasker/uTaskerUserFiles.PDF
If you do decide to use both make sure that the parameter block and the file system contents don't overlap with each other and that the code doesn't grow large enough to overlap with the start of the file system space - the documents in the directory above serves as a template for verifying this when designing new layouts.

Regards

Mark

[aaronlawrence]

Thanks Mark. I've turned all Flash support off because I really don't need it - or a web server, or FTP. It would have made a nice demo but I can't justify the time to get it working.

I've got the LAN8720 PHY working now, after some confusion over the address (somehow 1 in our board) and model number (datasheet wrongly says its 0x0C, but really 0x0F).

[FOXY]

Hi Mark and others
 Just to muddy the waters further, mark, you may need to consider the MCB2300 board in a slightly different light. 

You say (as do your defines) that this board has a 2378 chip.  My version 3 board
has a 100pin 2368 chip and a DP83848 Phy chip circa late 2006 according to the schematic! 

This may lead to some confusions when refering simply to MCB2300 board.

Good Luck

FOXY
Martin Fox

[mark]

Hi Martin

I never knew that they made versions with different chips on!

However the LPC2368 and LPC2378 should be basically compatible (the 100 pin one is missing the mini-external bus). Both boards use the same PHY (DP83848). and, as long as wire up th same and also using the same PHY address it should also be compatible.

2006 sounds like a very early board and so probably also with early engineering samples on. I don't think the mini-external bus worked in these and maybe there are some other bugs in these chips which could cause some 'funnies' ?

Regards

Mark

[mark]

Hi Aaron

I just checked the data sheet here: http://pdf1.alldatasheet.com/datasheet-pdf/view/312185/SMSC/LAN8720.html (Rev. 1.0 05-28-09)

It gives the model number as 0x0f for the LAN8720 and LAN8720i

Is it possible you used a different data sheet (either one which has an incorrect value, typo etc. or one belonging to a slightly different chip from SMSC)?

Regards

Mark

[aaronlawrence]

Yep, SMSC have screwed up their datasheet majorly. It used to be correct but the currently distributed one on their site seems to have a lot of data left over from the LAN8700. Pretty poor effort.
We've contacted them about this, of course ... :/
http://www.smsc.com/media/Downloads_Public/Data_Sheets/8720.pdf

[mark]

Oooops. They certainly messed something up in the newer doc...

Regards

Mark