2106 | ADC | ARM7 | Atmel | Bootloader | CAN | CrossStudio | CrossWorks | DDS | ECos | Ethernet | ETM | FIFO | FLASH | FPGA | GCC | GDB | GNU | GNUARM | GPIO | I2C | IAP | IAR | JTAG | Kickstart | LCD | Linux | LPC | LPC-E2294 | LPC2000 | LPC2100 | LPC2104 | Lpc2106 | Lpc210x | LPC2114 | LPC2119 | LPC2124 | LPC2129 | Lpc2138 | LPC213x | LPC21xx | LPC2210 | LPC2212 | LPC2214 | LPC2292 | LPC2294 | LPC2xxx | LPC3128 | MCB2100 | Olimex | Philips | PWM | Rowley | RTC | RTOS | SPI | SSP | UART | UART0 | UART1 | ULINK | USB | Watchdog | Wiggler

Hi, I'm writing an application for LPC2124 using ARM ADS 1.2 I want to save a few user-defined configuration bytes in the internal flash. I've tried to use the IAP (in application programming) as suggested by philips' user manual, but the LPC freezes when entering the "iap entry". Scatter def reserves upper 32 bytes of RAM exclusively for IAP code. ASM listing shows that args are passed in r0 and r1 as required. Are there any code examples or app notes around, on how to program the flash memory from an application that's itself running in flash memory? struct iap_t { unsigned long cmd; unsigned long arg0; unsigned long arg1; unsigned long arg2; unsigned long arg3; }; typedef void (*IAP)(struct iap_t *, unsigned long *); #define IAP_LOCATION 0x7ffffff1 IAP iap_entry =(IAP) IAP_LOCATION; #define FLASH_PARAM_ADDR 0x0001C000 void WriteEEPROM(void) { struct iap_t prepare_flash = { 50, 0, 0, 0, 0 }, erase_sector = { 52, 0, 0, 0, 0 }, copy_to_flash = { 51, 0, 0, 0, 0 }; unsigned long result[2]; disableIRQ(); prepare_flash.arg0 = prepare_flash.arg1 = FLASH_PARAM_ADDR / 0x2000; iap_entry(&prepare_flash, result); erase_sector.arg0 = erase_sector.arg1 = FLASH_PARAM_ADDR / 0x2000; erase_sector.arg2 = 18432; /* 18.432 MHz clk */ iap_entry(&erase_sector, result); iap_entry(&prepare_flash, result); copy_to_flash.arg0 = FLASH_PARAM_ADDR; copy_to_flash.arg1 = (unsigned long)eeprom_settings.EEPROMCC1020Config; copy_to_flash.arg2 = 512; copy_to_flash.arg3 = 18432; iap_entry(&copy_to_flash, result); enableIRQ(); }

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Hi, I'm writing an application for LPC2124 using ARM ADS 1.2 I want to save a few user-defined configuration bytes in the internal flash. I've tried to use the IAP (in application programming) as suggested by philips' user manual, but the LPC freezes when entering the "iap entry". Scatter def reserves upper 32 bytes of RAM exclusively for IAP code. ASM listing shows that args are passed in r0 and r1 as required. Are there any code examples or app notes around, on how to program the flash memory from an application that's itself running in flash memory? struct iap_t { unsigned long cmd; unsigned long arg0; unsigned long arg1; unsigned long arg2; unsigned long arg3; }; typedef void (*IAP)(struct iap_t *, unsigned long *); #define IAP_LOCATION 0x7ffffff1 IAP iap_entry =(IAP) IAP_LOCATION; #define FLASH_PARAM_ADDR 0x0001C000 void WriteEEPROM(void) { struct iap_t prepare_flash = { 50, 0, 0, 0, 0 }, erase_sector = { 52, 0, 0, 0, 0 }, copy_to_flash = { 51, 0, 0, 0, 0 }; unsigned long result[2]; disableIRQ(); prepare_flash.arg0 = prepare_flash.arg1 = FLASH_PARAM_ADDR / 0x2000; iap_entry(&prepare_flash, result); erase_sector.arg0 = erase_sector.arg1 = FLASH_PARAM_ADDR / 0x2000; erase_sector.arg2 = 18432; /* 18.432 MHz clk */ iap_entry(&erase_sector, result); iap_entry(&prepare_flash, result); copy_to_flash.arg0 = FLASH_PARAM_ADDR; copy_to_flash.arg1 = (unsigned long)eeprom_settings.EEPROMCC1020Config; copy_to_flash.arg2 = 512; copy_to_flash.arg3 = 18432; iap_entry(&copy_to_flash, result); enableIRQ(); }

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Hi, I'm writing an application for LPC2124 using ARM ADS 1.2 I want to save a few user-defined configuration bytes in the internal flash. I've tried to use the IAP (in application programming) as suggested by philips' user manual, but the LPC freezes when entering the "iap entry". Scatter def reserves upper 32 bytes of RAM exclusively for IAP code. ASM listing shows that args are passed in r0 and r1 as required. Are there any code examples or app notes around, on how to program the flash memory from an application that's itself running in flash memory? struct iap_t { unsigned long cmd; unsigned long arg0; unsigned long arg1; unsigned long arg2; unsigned long arg3; }; typedef void (*IAP)(struct iap_t *, unsigned long *); #define IAP_LOCATION 0x7ffffff1 IAP iap_entry =(IAP) IAP_LOCATION; #define FLASH_PARAM_ADDR 0x0001C000 void WriteEEPROM(void) { struct iap_t prepare_flash = { 50, 0, 0, 0, 0 }, erase_sector = { 52, 0, 0, 0, 0 }, copy_to_flash = { 51, 0, 0, 0, 0 }; unsigned long result[2]; disableIRQ(); prepare_flash.arg0 = prepare_flash.arg1 = FLASH_PARAM_ADDR / 0x2000; iap_entry(&prepare_flash, result); erase_sector.arg0 = erase_sector.arg1 = FLASH_PARAM_ADDR / 0x2000; erase_sector.arg2 = 18432; /* 18.432 MHz clk */ iap_entry(&erase_sector, result); iap_entry(&prepare_flash, result); copy_to_flash.arg0 = FLASH_PARAM_ADDR; copy_to_flash.arg1 = (unsigned long)eeprom_settings.EEPROMCC1020Config; copy_to_flash.arg2 = 512; copy_to_flash.arg3 = 18432; iap_entry(&copy_to_flash, result); enableIRQ(); }

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Hi, I'm writing an application for LPC2124 using ARM ADS 1.2 I want to save a few user-defined configuration bytes in the internal flash. I've tried to use the IAP (in application programming) as suggested by philips' user manual, but the LPC freezes when entering the "iap entry". Scatter def reserves upper 32 bytes of RAM exclusively for IAP code. ASM listing shows that args are passed in r0 and r1 as required. Are there any code examples or app notes around, on how to program the flash memory from an application that's itself running in flash memory? struct iap_t { unsigned long cmd; unsigned long arg0; unsigned long arg1; unsigned long arg2; unsigned long arg3; }; typedef void (*IAP)(struct iap_t *, unsigned long *); #define IAP_LOCATION 0x7ffffff1 IAP iap_entry =(IAP) IAP_LOCATION; #define FLASH_PARAM_ADDR 0x0001C000 void WriteEEPROM(void) { struct iap_t prepare_flash = { 50, 0, 0, 0, 0 }, erase_sector = { 52, 0, 0, 0, 0 }, copy_to_flash = { 51, 0, 0, 0, 0 }; unsigned long result[2]; disableIRQ(); prepare_flash.arg0 = prepare_flash.arg1 = FLASH_PARAM_ADDR / 0x2000; iap_entry(&prepare_flash, result); erase_sector.arg0 = erase_sector.arg1 = FLASH_PARAM_ADDR / 0x2000; erase_sector.arg2 = 18432; /* 18.432 MHz clk */ iap_entry(&erase_sector, result); iap_entry(&prepare_flash, result); copy_to_flash.arg0 = FLASH_PARAM_ADDR; copy_to_flash.arg1 = (unsigned long)eeprom_settings.EEPROMCC1020Config; copy_to_flash.arg2 = 512; copy_to_flash.arg3 = 18432; iap_entry(&copy_to_flash, result); enableIRQ(); }

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Hi, I'm writing an application for LPC2124 using ARM ADS 1.2 I want to save a few user-defined configuration bytes in the internal flash. I've tried to use the IAP (in application programming) as suggested by philips' user manual, but the LPC freezes when entering the "iap entry". Scatter def reserves upper 32 bytes of RAM exclusively for IAP code. ASM listing shows that args are passed in r0 and r1 as required. Are there any code examples or app notes around, on how to program the flash memory from an application that's itself running in flash memory? struct iap_t { unsigned long cmd; unsigned long arg0; unsigned long arg1; unsigned long arg2; unsigned long arg3; }; typedef void (*IAP)(struct iap_t *, unsigned long *); #define IAP_LOCATION 0x7ffffff1 IAP iap_entry =(IAP) IAP_LOCATION; #define FLASH_PARAM_ADDR 0x0001C000 void WriteEEPROM(void) { struct iap_t prepare_flash = { 50, 0, 0, 0, 0 }, erase_sector = { 52, 0, 0, 0, 0 }, copy_to_flash = { 51, 0, 0, 0, 0 }; unsigned long result[2]; disableIRQ(); prepare_flash.arg0 = prepare_flash.arg1 = FLASH_PARAM_ADDR / 0x2000; iap_entry(&prepare_flash, result); erase_sector.arg0 = erase_sector.arg1 = FLASH_PARAM_ADDR / 0x2000; erase_sector.arg2 = 18432; /* 18.432 MHz clk */ iap_entry(&erase_sector, result); iap_entry(&prepare_flash, result); copy_to_flash.arg0 = FLASH_PARAM_ADDR; copy_to_flash.arg1 = (unsigned long)eeprom_settings.EEPROMCC1020Config; copy_to_flash.arg2 = 512; copy_to_flash.arg3 = 18432; iap_entry(&copy_to_flash, result); enableIRQ(); }

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

On 9 Dec 2004 at 10:18, Robert Adsett wrote: > At 03:05 PM 12/9/04 +0000, you wrote: > > > > > > The STMicroelectronics STR71x looks very good - some features are > > > superior to the LPC2xxx, such as 4 UARTS and 12-bit ADC. > > > > > > Is this group strictly Philips LPC2xxx? Should I go elsewhere if I > > > decide to use the STR71x? Are there any considerations to expand > > > the group's scope? > > > >As far as I can tell, there are three "small" ARMs of interest: SAM7, > >LPC2000, and STR7xx. > > Four, there is the ADuC series from Analog Devices as well. Five, once the Freescale (Formerly Motorola) MAC7000 device becomes available for other non automotive customers. These device look very good as well. The Freescale peripherals tend to be sorted out. One can generally assume that one can use one feature AND another feature. On the LPC2xxx devices it often seems a case of one feature OR another feature. [Stuff Snipped] Regards Anton Erasmus -- A J Erasmus

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Hi, I think Leon made it pretty clear that there are 1. ARM groups not dedicated to an implementations 2. Options to start a dedicate group for a different device The LPCgroup is 99% talking about available devices, the LPCs, we know that many players intend to provide devices that compete with the LPCs Motorola stating clearly on their website that these devices are only available to tier one automotive customers (who are probably not very active in this group), why bother and talk about it. According to the moderator of this group, Leon it should be focused on the LPC devices. p.s. no offense , Bob --- In , "Anton Erasmus" <antone@s...> wrote: > On 9 Dec 2004 at 10:18, Robert Adsett wrote: > > > > > At 03:05 PM 12/9/04 +0000, you wrote: > > > > > > > > > The STMicroelectronics STR71x looks very good - some features are > > > > superior to the LPC2xxx, such as 4 UARTS and 12-bit ADC. > > > > > > > > Is this group strictly Philips LPC2xxx? Should I go elsewhere if I > > > > decide to use the STR71x? Are there any considerations to expand > > > > the group's scope? > > > > > >As far as I can tell, there are three "small" ARMs of interest: SAM7, > > >LPC2000, and STR7xx. > > > > Four, there is the ADuC series from Analog Devices as well. > > Five, once the Freescale (Formerly Motorola) MAC7000 device becomes available > for other non automotive customers. These device look very good as well. The > Freescale peripherals tend to be sorted out. One can generally assume that one can > use one feature AND another feature. On the LPC2xxx devices it often seems a case > of one feature OR another feature. > [Stuff Snipped] > > Regards > Anton Erasmus > -- > A J Erasmus

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Hi, > I think Leon made it pretty clear that there are 1. ARM > groups not dedicated to an implementations 2. Options to > start a dedicate group for a different device > > The LPCgroup is 99% talking about available devices, the > LPCs, we know that many players intend to provide devices > that compete with the LPCs Motorola stating clearly on their > website that these devices are only available to tier one > automotive customers (who are probably not very active in > this group), why bother and talk about it. > > According to the moderator of this group, Leon it should be > focused on the LPC devices. > > p.s. no offense , Bob I, for one, am interested in new devices that come along and am grateful for the Rob's exposition of the new Freescale part. TI also have the TMS470 becoming available through distribution, but we've yet to see one of these parts. -- Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk CrossWorks for MSP430, ARM, and now AVR processors

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

At 10:14 PM 12/17/04 +0200, you wrote: >On 9 Dec 2004 at 10:18, Robert Adsett wrote: > > > > > At 03:05 PM 12/9/04 +0000, you wrote: > > > > > > > > > The STMicroelectronics STR71x looks very good - some features are > > > > superior to the LPC2xxx, such as 4 UARTS and 12-bit ADC. > > > > > > > > Is this group strictly Philips LPC2xxx? Should I go elsewhere if I > > > > decide to use the STR71x? Are there any considerations to expand > > > > the group's scope? > > > > > >As far as I can tell, there are three "small" ARMs of interest: SAM7, > > >LPC2000, and STR7xx. > > > > Four, there is the ADuC series from Analog Devices as well. > >Five, once the Freescale (Formerly Motorola) MAC7000 device becomes available >for other non automotive customers. These device look very good as well. The >Freescale peripherals tend to be sorted out. One can generally assume that >one can >use one feature AND another feature. On the LPC2xxx devices it often seems >a case >of one feature OR another feature. This time when I went looking they actually appeared. However the smallest I saw was in a 112 pin package. Not exactly in the same league. Did I miss some? Robert " 'Freedom' has no meaning of itself. There are always restrictions, be they legal, genetic, or physical. If you don't believe me, try to chew a radio signal. " Kelvin Throop, III

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In , "Paul Curtis" <plc@r...> wrote: > Hi, > > > I think Leon made it pretty clear that there are 1. ARM > > groups not dedicated to an implementations 2. Options to > > start a dedicate group for a different device > > > > The LPCgroup is 99% talking about available devices, the > > LPCs, we know that many players intend to provide devices > > that compete with the LPCs Motorola stating clearly on their > > website that these devices are only available to tier one > > automotive customers (who are probably not very active in > > this group), why bother and talk about it. > > > > According to the moderator of this group, Leon it should be > > focused on the LPC devices. > > > > p.s. no offense , Bob > > I, for one, am interested in new devices that come along and am grateful > for the Rob's exposition of the new Freescale part. TI also have the > TMS470 becoming available through distribution, but we've yet to see one > of these parts. Me to, what about the new ATMEL low pin count devices, said to be alot cheaper then LPC and have more things in them! http://www.atmel.com/dyn/products/product_card.asp?part_id=3522 Any users group, anyone got a test drive of these? Reg KD

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

On 17 Dec 2004 at 22:34, Robert Adsett wrote: > At 10:14 PM 12/17/04 +0200, you wrote: > > >On 9 Dec 2004 at 10:18, Robert Adsett wrote: > > > > > > > > At 03:05 PM 12/9/04 +0000, you wrote: > > > > > > > > > > > > The STMicroelectronics STR71x looks very good - some features > > > > > are superior to the LPC2xxx, such as 4 UARTS and 12-bit ADC. > > > > > > > > > > Is this group strictly Philips LPC2xxx? Should I go elsewhere > > > > > if I decide to use the STR71x? Are there any considerations to > > > > > expand the group's scope? > > > > > > > >As far as I can tell, there are three "small" ARMs of interest: > > > >SAM7, LPC2000, and STR7xx. > > > > > > Four, there is the ADuC series from Analog Devices as well. > > > >Five, once the Freescale (Formerly Motorola) MAC7000 device becomes > >available for other non automotive customers. These device look very > >good as well. The Freescale peripherals tend to be sorted out. One > >can generally assume that one can use one feature AND another > >feature. On the LPC2xxx devices it often seems a case of one feature > >OR another feature. > > This time when I went looking they actually appeared. However the > smallest I saw was in a 112 pin package. Not exactly in the same > league. Did I miss some? IMO devices based on an ARM core with built-in flash and RAM are all in the same category. The size of the package as such - within reason does not exclude a device from this group. Even a 112 pin TQSOP is still quite small for essentially a complete 32-bit computer. Regarding te matter whether these other ARMs should be discussed here. IMO announcing alternatives here is good. Discussing differences in implimentations is good. Especially pointing out gotchas that might be present in either the LPC2xxx device or the alternative (i.e. not present in the LPC2xxx). Discussing non LPC2xxx devices outside this context should be done in an alternative list/group. Regards Anton Erasmus -- A J Erasmus

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Hi, > > I, for one, am interested in new devices that come along and am > grateful > > for the Rob's exposition of the new Freescale part. TI also have > the > > TMS470 becoming available through distribution, but we've yet to > see one > > of these parts. > > Me to, what about the new ATMEL low pin count devices, said > to be alot cheaper then LPC and have more things in them! > http://www.atmel.com/dyn/products/product_card.asp?part_id=3522 > Any users group, anyone got a test drive of these? Well, the SAM7 things exist as we have a board with a production device on. -- Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk CrossWorks for MSP430, ARM, and now AVR processors

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Hi – I have also seen one SAM7 eval-board in hands of our local distributor EBV – mid October. However – it is good to remain cautious about “non-reported bugs”, I encountered this experience with “another” ARM core (not Philips nor Atmel) and as photomask cost are expensive in 0.18µm (or below) – it can take some time before they will do a 2nd run – most likely during their first run samples were available only in very limited quantity and only for big target OEMs. However I am sure that LPC2100 family is a modern, generic and speedy version of the ARM7TDMI-S core with their PLL and VPB improvements – I like this chip very much :-) I hope that Philips will come soon out with ARM920T version with Flash, USB2 (OTG) and – w/o 10BT MAC. Cheers, Michel -----Original Message----- From: Paul Curtis [mailto:] Sent: zaterdag 18 december 2004 12:37 To: Subject: RE: [lpc2000] Non-LPC (was Re: LPC2xxx vs STR71x heresy?) Hi, > > I, for one, am interested in new devices that come along and am > grateful > > for the Rob's exposition of the new Freescale part. TI also have > the > > TMS470 becoming available through distribution, but we've yet to > see one > > of these parts. > > Me to, what about the new ATMEL low pin count devices, said > to be alot cheaper then LPC and have more things in them! > http://www.atmel.com/dyn/products/product_card.asp?part_id=3522 > Any users group, anyone got a test drive of these? Well, the SAM7 things exist as we have a board with a production device on. -- Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk CrossWorks for MSP430, ARM, and now AVR processors Yahoo! Groups Sponsor ADVERTISEMENT <http://us.ard.yahoo.com/SIG=129kmi85g/M=294855.5468653.6549235.3001176/D=gr oups/S=1706554205:HM/EXP=1103456587/A=2455396/R=0/SIG=119u9qmi7/*http:/small business.yahoo.com/domains/> click here <http://us.adserver.yahoo.com/l?M=294855.5468653.6549235.3001176/D=groups/S= :HM/A=2455396/rand=229461512 _____ > Service. [Non-text portions of this message have been removed]

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

>The LPCgroup is 99% talking about available devices, the LPCs, we know >that many players intend to provide devices that compete with the LPCs >Motorola stating clearly on their website that these devices are only >available to tier one automotive customers (who are probably not very >active in this group), why bother and talk about it. BTW: TI even makes ARM7 devices entirely only for high-volume automobile customers. Happy christmas - - Henry <Schau auch mal auf meine Homepage www.ehydra.dyndns.info> <u.a. Versand von Wasserflohzuchtansatz, Wasserpflanzen/-schnecken, Futteralge Chlorella, brasilianischer Sauerklee, Natron zum Backen/Baden, Chemikalien u.a.> <Alternativ über http://people.freenet.de/algenkocher

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )