µTasker Forum

µTasker Forum => NXPTM LPC2XXX and LPC17XX => Topic started by: mark on January 23, 2010, 02:23:02 AM

Title: LPC17XX Preliminary Information
Post by: mark on January 23, 2010, 02:23:02 AM
Hi All

A few people have been asking about whether, or when, support for the LPC17XX will be added. This is a Cortex M3 based chip which fits in well with the LPC2XXX range - it uses much the same peripherals and is even compatible at the port pin level. With up to 512k internal FLASH, 64k SRAM, processor running at up to 120MHz, Ethernet, USB (host, device/OTG) and various other stuff in 100 or 80 pin package it is indeed an interesting device.

So, armed with an Olimex LPC1766-STK the new chips was slowly taken into action. With the basic uTasker project now working with UARTs, uFileSystem and SD card (utFAT) together with Ethernet FTP and web server, it is time to announce that this port is indeed under construction and nearing a stage of Beta release.

Owners of an LPC1766-STK can already test drive it here: http://www.utasker.com/SW_Demos.html#LPC17XX

Here is an overview of these devices:

LPC1769

LPC1768

LPC1766
      
LPC1765

LPC1764

LPC1759

LPC1758

LPC1756

LPC1754

LPC1752

LPC1751

Watch this space for more detail soon...;-)

Regards

Mark
Title: Re: LPC17XX Preliminary Information
Post by: jezc on January 23, 2010, 10:24:54 PM
Hi Mark,

I'll be very interested to get up and running with these devices - not least with the planned release of the upgrade for the LPC24xx family (including 2478) for the middle of this year!

Is there any plan in the near future to add/exterd the USB support for these or the LPC2xxx ports?

Any more info you're prepared to release will be most welcome on this :-)

Cheers,
    JezC
Title: Re: LPC17XX Preliminary Information
Post by: mark on January 24, 2010, 02:01:08 AM
Hi Jez

There are two main open points concerning the LPC family:
1) USB
2) SD controller

The LPC17XX doesn't have the SD controller but both LPC2XXX and LPC17XX types have USB.
The basic USB is device mode (which is already available for SAM7X and M522XX projects, plus a Beta in the Luminary Micro project).
Host now makes also much more sense since it can interface with the utFAT module for mass-storage work (memory sticks). Some types also have OTG which would be interesting, although there hasn't been any real demand for it that I noticed.

The only problem here is that each chip has a completely different USB controller and they are rather difficult to get working - I have only written "device" drivers up until now so still need to learn about host mode...

I do hope that at least the LPC device mode will be possible in the near future, but I can't give a date just at the moment. When would you need it and which mode would it be working in?

Regards

Mark
Title: Re: LPC17XX Preliminary Information
Post by: jezc on January 24, 2010, 10:21:27 PM
Hi Mark,

Eventually I'd be interested in both USB device & USB host support (the LPC24xx have two USB interfaces and we are currently configuring one as s device and one as a hos, though as far as I know the LPC17xx only have a single USB interface).

There are some useful examples on the NXP site to help you get the USB working in host mode though the documentation could be a bit more helpful at times. It's allowed us to verify that our hardware for USB Host works ok (for connecting to USB per drives for example) which is a good start.

Later on we may even need to add HID support (keyboard / mouse) but there's no timescale for this yet.

I'm not asking for faster development on either device or host for the LPC family, just any idea of when you're planning to roll it out ;-)

I'm interested in many of your other future developments as well, so I don't want to upset those!

Let me know if I can help you with the USB host in some way!

Cheers,
    Jez
Title: Re: LPC17XX Preliminary Information
Post by: mark on January 24, 2010, 11:39:30 PM
Hi Jez

The highest priority at the moment is IPv6. This was planned for the first month of 2010 - its development has started but may take a bit longer than expected.

I will have a go at getting LPC USB device (I hope that the LPC2xxx and LPC17XXX USB controllers are as compatible as possible) ready as next point. The LPC project has in fact started to become more popular recently and this also give motivation to invest more time there. Maybe by mid...end February 2010(?). Depending on how this goes host can then be looked at.

Note that I updated the demo code http://www.utasker.com/SW_Demos.html#LPC17XX to include also uGLCDLIB1.1 LCD demo on the NOKIA LCD that the board has.

Regards

Mark
Title: Re: LPC17XX Preliminary Information
Post by: aaronlawrence on January 26, 2010, 01:17:20 AM
Comment: in my experience USB host is a nightmare to get working. For one thing there are a squillion possible device types, but perhaps the biggest problem seems to be:

creators of devices (e.g. memory sticks) generally only test them against Windows. Windows has a huge number of sophisticated capabilities, including many workarounds for bad device behaviour. Thus, when you take random "mass storage compliant" memory stick and try to use it according to the specs, it doesn't quite work.

we tried to get USB host for memory sticks working with Windows CE, and neither microsoft nor our BSP developer could get them working reliably across even a decent percentage of consumer memory sticks. They either didn't work at all or worked so slowly (16kB/sec!) as to be useless. One other vendor I saw spent ages working on the microsoft stack and fixed many bugs/workarounds; he went from 50% of his sample sticks working to near 90%...
Title: Re: LPC17XX Preliminary Information
Post by: mark on January 26, 2010, 05:55:21 PM
Hi Aaron

Yes this is certainly a problem in the embedded world.
See the following from Freescale and their free MQS USB stack: http://forums.freescale.com/freescale/board/message?board.id=MQXGEN&message.id=199&query.id=114082#M199

This may also be an explanation for the popularity of SD cards over memory sticks for such applications. I think that for exchanging data memory sticks are more practical, whereas SD cards are in comparison a bit fiddly, breakable and losable, but they are smaller and lighter (especially the microSD ones).

Memory sticks always strike me as being overcomplicated since they are more or less SD cards with an extra USB host/device between them, but are certainly practical like that for work together with PCs. Since one can also plug in an SD card into a memory stick adapter, costing about $5 to buy, I think that the embedded world could probably live without memory sticks almost entirely.

But maybe some circumstances still prefer USB memory sticks and I think that it would be interesting to at least have minimum support for these. The fact that there will be USB memory sticks out there - and probably a lot of them - that prove not to work (without extra tuning for the particular models) will have to be generally accepted as a fact of life in this case. A list of popular USB sticks which are readily obtainable and have proven to work is probably the way to go here - anything not on this list should simply be avoided; otherwise stick to SD cards...

Regards

Mark
Title: Re: LPC17XX Preliminary Information
Post by: aaronlawrence on February 19, 2010, 01:36:35 PM
Yes, for some cases the "well known supported brand" approach could be useful.
However that sort of negates the benefit of USB memory support, since people expect to be able to use any ubiquitous stick ...
We are trying again at USB mass storage host, but not depending on it. We are now on an x86 platform for our main board, so the USB host  is more standardised (OHCI?) and seems to work so far...

Any custom USB driver with mass storage = run away :)
Title: Re: LPC17XX Preliminary Information
Post by: mark on February 19, 2010, 01:57:20 PM
Hi Aaron

I noticed that my daughter's cheap hi-fi system with Tape deck, CD, radio also has slots for SD cards and USB sticks (and plays MP3 from them).
This made me also wonder whether they have potential problems with USB sticks - there was no special notes in the instructions so maybe it is possible with, supposedly small and cheap processors...[I didn't take it apart but would expect to find a solution with just a couple of chips on  cardboard type PCB].

Regards

Mark
Title: Re: LPC17XX Preliminary Information
Post by: aaronlawrence on March 06, 2010, 04:25:31 AM
Oh, I believe it's possible alright, you just have to spend a lot of time debugging and working around stuff.  Probably using Linux would help, because then everyone's efforts are shared, unlike Windows.
Title: Re: LPC17XX Preliminary Information
Post by: jezc on June 03, 2010, 01:06:14 PM
Hi,

Would another option be to use a USB to SD card adaptor to provide USB host data storage support but without the problems arising from the many different flavours of USB Mass storage devices?

Just thinking (/hoping!) that once the USB to SD adaptor was working it should then basically work with any SD card plugged into it...

I'm not sure if SDHC support would be the next hurdle to overcome - anyone got any experience here?

We can't easily fit a removable SD card (or miniSD or microSD) in our products but we do have the USB Host connection available.

Cheers,
    Jez

Title: Re: LPC17XX Preliminary Information
Post by: jezc on June 10, 2010, 12:45:30 PM
Hi Mark,

I've just managed to borrow a Keil MCB1760 dev board (again) to go with the IAR equivalent I've had for quite a while.

Do you still want to know if uTasker works on the Keil board?

If so, I'll try and give it a brief run tonight and let you know how it goes.

Cheers,
    Jez
Title: Re: LPC17XX Preliminary Information
Post by: mark on June 10, 2010, 01:42:47 PM
Hi Jez

If you get the chance that would of course be great. I am not sure whether someone already tried this or not so any feedback as reference would be useful.

Tell me also if you are interested in USB device since I do have this in my development version (for LPC2XXX and LPC17X since they are compatible). I didn't complete DMA mode operation (it still does something strange that still needs to be looked into) but the interrupt mode seems to be essentially workable.

Regards

Mark

Title: Re: LPC17XX Preliminary Information
Post by: jezc on June 11, 2010, 10:23:04 AM
Hi Mark,

I will do - didn't get chance to try it last night but will make sure I do over the weekend.

We are interested in the USB support - I'll be interested to try this when it's available - but I'm not sure if we need the DMA. I can try it with the interrupt mode only as a first step and then let you know if the DMA would be useful.

Is the LPC17xx support in the normal LPC2xxx archive? I've just checked the download (using the link from the v1.4 e-mail in January) but I can't see any LPC17xx support...

Cheers,
    Jez
Title: Re: LPC17XX Preliminary Information
Post by: mark on June 11, 2010, 01:24:52 PM
Hi Jez

I just sent you the LPC17XX Beta. It is the fist version still so doesn't have all peripherals or USB but should hopefully run on your Keil board (Ethernet, serial, SD card).

Regards

Mark
Title: Re: LPC17XX Preliminary Information
Post by: jezc on June 14, 2010, 12:46:05 PM
Hi Mark,

I can't find a project for IAR (v4 or v5) in the beta of LPC17xx that I downloaded...I can see the folders for GNU/Rowley/uVision etc.

Is there any support for IAR (preferably v5 but I do still have v4.42 installed as well)? I think you had a bit of a fight with the i76 file back in March...

Cheers,
    Jez
Title: Re: LPC17XX Preliminary Information
Post by: mark on June 14, 2010, 01:00:58 PM
Hi Jez

I have just sent you the IAR5 project (there will be no IAR4 project).

I believe that I added it at the end of January 2010 (presumably tested but I don’t remember the details). This was probably just after the Beta version was made so not in the package.

Copy the folder to the directory \Applications\uTaskerV1.4

Good luck

Regards

Mark

Title: Re: LPC17XX Preliminary Information
Post by: jezc on June 15, 2010, 01:01:06 PM
Hi Mark,

No problem re there being no IAR v4 project - v5 is my preference anyway  ;D

Ok, got the project file & copied into the existing file/folder structure.

I've tried compiling it for both the Olimex (LPC1766) & Keil (LPC1768) boards by changing config.h (#ifdef _LPC17XX) but both are giving an error "Error[Ta058]:ARM mode is not available in this core"

The first case for this is in LPC17XX.x, at line168
extern __interrupt void _start(void);

The problems mostly seem to relate to the use of __interrupt

Have I missed a change I need to make in config.h (or elsewhere)? I can see this being defined around line 54 in LPC17XX.c and if I change it so that the __arm is omitted (as for the non-IAR compiler case) that gets rid of the error re ARM mode.

That then leaves me with 5 other errors:-

Warning[Pe111]: statement is unreachable C:\Downloads\uTasker\uTaskerV1.4B_LPC17XX\Hardware\LPC17XX\LPC17XX.c 300
Error[Pe513]: a value of type "void (__interwork __irq *)(void)" cannot be assigned to an entity of type "void (*)(void)" C:\uTaskerV1.4B_LPC17XX\Hardware\LPC17XX\LPC17XX.c 523
Error[Pe167]: argument of type "void (__interwork __irq *)(void)" is incompatible with parameter of type "void (*)(void)" C:\uTaskerV1.4B_LPC17XX\Hardware\LPC17XX\LPC17XX.c 1467
Error[Pe167]: argument of type "void (__interwork __irq *)(void)" is incompatible with parameter of type "void (*)(void)" C:\uTaskerV1.4B_LPC17XX\Hardware\LPC17XX\LPC17XX.c 1470
Error[Pe167]: argument of type "void (__interwork __irq *)(void)" is incompatible with parameter of type "void (*)(void)" C:\uTaskerV1.4B_LPC17XX\Hardware\LPC17XX\LPC17XX.c 1473
Error[Pe167]: argument of type "void (__interwork __irq *)(void)" is incompatible with parameter of type "void (*)(void)" C:\uTaskerV1.4B_LPC17XX\Hardware\LPC17XX\LPC17XX.c 1476
Error while running C/C++ Compiler

I'm presuming that there's a similar change required to remove the interwork mode (which I think is an ARM/Thumb mode, not available for Thumb2 as used by Cortex-M3 ?) but I've not found this one yet.

Cheers,
    Jez
Title: Re: LPC17XX Preliminary Information
Post by: mark on June 15, 2010, 02:12:04 PM
Hi Jez

I just looked into the state of the Beta and confirm the compiler errors.

To get around the first problem simply define

#define __interrupt

__interrupt is never needed with the Cortex M3

In the Beta version there is still the following:

#if defined COMPILE_IAR || defined COMPILE_KEIL
    #if defined COMPILE_IAR
        #define __interrupt   __irq __arm
    #else
        #define __interrupt   __irq
        #define __root
    #endif
#else
    #define __interrupt
    #define __root
#endif

This can be deleted since it is otherwise setting the __irq __arm, which is invalid for IAR and the Cortex M3.


There is however another problem due to the way that IAR works. Looking in my notes I found that we discussed this back in January in private email exchanges when I was making the IAR5 adaptations. I have copied this here (check your mail from 29.1.2010 for the original. With this it compiles and links so there is still hope for your Keil board ;-)

Regards

Mark



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

I now have a compatible solution for the IAR checksum case.

In lpc17xx.h

typedef struct stVECTOR_TABLE_MINIMUM
{
    RESET_VECTOR  reset_vect;
    unsigned long ulDummyNMI;
    unsigned long ulDummyHardFault;
    unsigned long ulDummyMemMan;
    unsigned long ulDummyBusFault;
    unsigned long ulDummyUsageFault;
#ifndef COMPILE_IAR5
    unsigned long ulLPC1XXX_CS;
#endif
} VECTOR_TABLE_MINIMUM;

In lpc17xx.c

// The initial stack pointer and PC value - this is linked at address 0x00000000
//
#if defined COMPILE_IAR5
__root const VECTOR_TABLE_MINIMUM __vector_table @ ".intvec"               // __root forces the function to be linked in IAR project
#elif defined COMPILE_IAR
__root const VECTOR_TABLE_MINIMUM reset_vect @ "RESETVECT"                 // __root forces the function to be linked in IAR project
#elif defined _GNU
const VECTOR_TABLE_MINIMUM __attribute__((section(".vectors"))) reset_vect
#elif defined _COMPILE_KEIL
__attribute__((section("RESET"))) const VECTOR_TABLE_MINIMUM reset_vect
#else
const VECTOR_TABLE_MINIMUM reset_vect
#endif
= {
    {
        (void *)(RAM_START_ADDRESS + SIZE_OF_RAM),                       // stack pointer to top of RAM
        (void (*)(void))START_CODE,                                      // start address
    },
    0x53415475,                                                          // dummy vector values (for recognition)
    0x2052454b,
    0x3143504c,
    0x20585858,
    0x2e522e43,
#ifndef COMPILE_IAR5
    0xffffffff,                                                          // blank for check sum
#endif
};

#if defined COMPILE_IAR5
    __root const unsigned long __vector_table_0x1c @ ".intvec" = 0xffffffff;
#endif

This allows the .icf file to be left as it was. Since the IAR linker finds the variable __vector_table_0x1c at the correct location it then fills it out correctly.

Below is a copy of my developer’s log in case you need more background info.

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



Reset and Interrupt vectors
The reset is slightly different in comparison to the LPC2XXX. The first location in FLASH is the initial value of the Stack pointer and the second is the PC value to be loaded. Following this there are interrupt vectors similar to the ARM7 (although not identical). To get an idea of the layout the vector tables struc is shown here:

typedef struct stVECTOR_TABLE
{
    RESET_VECTOR  reset_vect;
    void  (*ptrNMI)(void);
    void  (*ptrHardFault)(void);
    void  (*ptrMemManagement)(void);
    void  (*ptrBusFault)(void);
    void  (*ptrUsageFault)(void);
    void  *ptrReserved1[4];
    void  (*ptrSVCall)(void);
    void  (*ptrDebugMonitor)(void);
    void  *ptrReserved2;
    void  (*ptrPendSV)(void);
    void  (*ptrSysTick)(void);
    PROCESSOR_IRQ processor_interrupts;                                  // length is processor specific
} VECTOR_TABLE;


After the reset vector (the initial SP and initial PC values) there are the first 5 fixed interrupt vectors. These are followed by 4 reserved locations. In a similar manner to the LPC2XXX the first of these reserved locations are used as check sum by the internal boot loader. The values of the reset vector plus the first 5 interrupt vectors are used to calculate the value that the boot loader expects to find at the first reserved location (long word addressed at 0x1c).
The Cortex M3 doesn’t need the interrupt vectors to be located here since they can be remapped to other locations; even when this is the case (as in the µTasker project) it is necessary to keep the location 0x1c free – its value is generally calculated when downloading the code. The µTasker project this uses a few fixed values, with 0xffffffff at 0x1c so that the boot’s check sum can be correctly set.
 
Since the Cortex M3 allows assembler code to be avoided in most situations the µTasker project also attempts to stick with this strategy wherever possible. This helps in keeping code portable and also in understanding its operation – assembler code is often specific to a particular compiler and is not always immediately understandable when written for a different compiler packages as one is used to.
The reset vector (actually a reduced version of the vector table) can be found in LPC17XX.c.



const VECTOR_TABLE_MINIMUM __attribute__((section(".vectors"))) reset_vect = {
    {
        (void *)(RAM_START_ADDRESS + SIZE_OF_RAM), // stack pointer to top of RAM
        (void (*)(void))START_CODE,                // start address
    },
    0x53415475,                           // dummy vector values (for recognition)
    0x2052454b,
    0x3143504c,
    0x20585858,
    0x2e522e43,
    0xffffffff,                           // blank for check sum
};


The constant table is forced to be at address 0x00000000 (section .vectors in the GCC linker script file) – this is also a bit compiler dependent but an appropriate form exists in the code to suit the supported compilers.
Since the interrupts are located in SRAM for actual use the values before the reserved location which is used as a checksum are not of importance – they are in fact ASCII for “uTASKER LPC1xxx C.S.” for recognition by a debugger. When the code is downloaded by FlashMagic or Rowley, etc. the checksum will automatically be added.
IAR is an exception since it doesn’t add the checksum automatically when it loads the code. It requires that an automated post-linking step performs it by modifying the generated file.
This is controlled by the file LPC1766.i76 in the IAR directory arm\config\devices\NXP\ which includes a direction
NXPLPCchecksum=__vector_table_0x1c:4,sum32:2;__vector_table-__vector_table+0x1B
If this is removed from the file the file can still be loaded using FlashMagic but the check sum will be missing if loaded from within IAR. If the direction is left in the linker step will fail unless it can find the location that it wants to calculate and modify.
 
To solve this, the following change was made to suit IAR:


#if defined COMPILE_IAR5
__root const VECTOR_TABLE_MINIMUM __vector_table @ ".intvec"               // __root forces the function to be linked in IAR project
#elif defined _GNU
const VECTOR_TABLE_MINIMUM __attribute__((section(".vectors"))) reset_vect
#elif defined _COMPILE_KEIL
__attribute__((section("RESET"))) const VECTOR_TABLE_MINIMUM reset_vect
#else
const VECTOR_TABLE_MINIMUM reset_vect
#endif
= {
    {
        (void *)(RAM_START_ADDRESS + SIZE_OF_RAM), // stack pointer to top of RAM
        (void (*)(void))START_CODE,      // start address
    },
    0x53415475,                          // dummy vector values (for recognition)
    0x2052454b,
    0x3143504c,
    0x20585858,
    0x2e522e43,
#ifndef COMPILE_IAR5
    0xffffffff,                          // blank for check sum
#endif
};
#if defined COMPILE_IAR5
    __root const unsigned long __vector_table_0x1c @ ".intvec" = 0xffffffff;
#endif


This definition of VECTOR_TABLE_MINIMUM is also modified in this case to be one long word shorter, after which the compulsory variable is positioned. This allows the check sum to be inserted by IAR during the linking phase.

***************************************************
Title: Re: LPC17XX Preliminary Information
Post by: jezc on June 15, 2010, 03:20:52 PM
Hi Mark,

Thanks - I've got the code to compile ok now, just trying to get it to load onto the Keil dev board (via the IAR debugger if possible, which we use for our own development stuff).

Think I've got it sorted - hooray : LED P2.3 is now flashing .... ;D

Now I can try and get my own development rolling on the Keil board - I'll revisit the Olimex board again later and let you know how that one goes.

Thanks for all the help!

Cheers,
    Jez
Title: Re: LPC17XX Preliminary Information
Post by: jezc on June 16, 2010, 12:44:07 PM
Hi Mark,

I'm pleased to report that it works fine on the Olimes 1766 board as well - LED 1 flashes, LED 2 constantly on.

Any idea when the USB support may be rolled out for this (LPC17xx) family?

Cheers,
    Jez
Title: Re: LPC17XX Preliminary Information
Post by: mark on June 16, 2010, 02:26:11 PM
Hi Jez

I am presently implementing MSD (Mass Storage Device) and have this essentially working on a Coldfire.

As reference, the save speed is 180kBytes/s and retrieve speed 267kBytes/s (USB full speed transfer + SPI SD card interface).

It didn't work correctly on the SAM7X (there is some data corruption when writing, which I need to solve).

I will give it a try on the LPC17XX Olimex board since this has SD card slot on SPI. If it works in interrupt mode (I know that DMA is not ready) I will send you the update so that you can see it in action (CDC and MSD). If not, I will maybe be able to estimate how much work may be needed.

Regards

Mark
Title: Re: LPC17XX Preliminary Information
Post by: mark on June 17, 2010, 12:02:51 AM
Hi Jez

I gave it a try and I could read data from the SD card.

However I couldn't write. This means that the transfer direction from PC to the board looks to need some work. (Similar but not identical to the SAM7X case).

Give me a couple of days and I may be able to solve this. Then I can compare transfer speeds between the devices as a ball-park and I'll send you a version for your own tests.

Regards

Mark
Title: Re: LPC17XX Preliminary Information
Post by: jezc on June 17, 2010, 10:22:39 AM
Hi Mark,

Sounds promising - I won't really be in a position to get to that part of the project for about a week or more, so if it's easier to aim for sometime late next week that would be fine for me!

(I'm trying to prove as much of the operation as I can on the LPC2478 at the moment & will be seeing how much works without change on the LPC176x once the basic functionality is pretty much there...)

Cheers,
    Jez