From richard at imagecraft.com Tue Aug 14 03:05:24 2007 From: richard at imagecraft.com (Richard) Date: Tue Aug 14 03:17:37 2007 Subject: [Icc-arm] Product News Message-ID: <200708141017.l7EAHXTL058581@dragonsgate2.imagecraft.com> With all the developments going on, sometimes it is hard to keep track of things. There is also some rumors that we are emphasizing certain compilers less etc. so hopefully this email will also address some of those concerns. Obviously, we are in the business to make money, I have always believe that by providing excellent support, a decent development toolset, plus the low cost factor, that we would be able to make a decent living. I see no reason to change from that philosophy. ImageCraft is relatively speaking a small company, but then again, so is the embedded tools market. A million unit a year gadget may only need one copy of the compiler for development! This is a challenging market. There are gazillions devices out there, each with a potential market of only a few thousand compiler licenses in total at best. With multiple fishes in the pond, the feeding can get thin indeed. Then you have brilliant silicon manufacturers who think that it is in their best interest to have their own software tools, not caring that it is an effective way to drive away their third party tool vendors. So we have to adjust. We have to look at the potential markets and react, we have to change our development team setup, we have to look ahead and come up with effective strategies and tactics. Given this light, the last thing we want to do is to abandon our existing markets. While we believe the growth markets would likely be the AVR and ARM, there is no reason not to continue to develop for the HCS12 and MSP430 platforms. Especially with the new generations of the S12X and MSP430X devices coming in, the market potential is bigger than ever. But we need to be smarter. May be we should look into educational kits with detail examples and an easy to use board bundles. Perhaps we need to add more companion products such as a RTOS. May be we need to be more aggressive in making sure users pay for the annual maintenance.... Of course, coming from a techie background, most importantly, we have to continue to improve on our technologies. The MIO global optimizer is working well and we have come up with a plan to improve the performance further. We need to implement features like __far and __flash to support certain chip features better (paged function under S12 and flash items under AVR), and we need to deliver the 64 bits FP support. And we need to widen the net farther. We are very excited about the new Parallax Propeller chips. 8 32 bits core on a single chip. While it is not a microcontroller per se, the chip has a lot of potential. A Propeller C, which is under development, is potentially huge. Beyond that, the Atmel AVR32 is a natural target for us, and we have new resources with Eclipse expertise so we would be able to leverage the Studio32 platform from day one. Oh, BTW, relating to that, we will be releasing an AVR Studio plugin for ICCAVR soon and users than can use one single IDE for the AVR platform. All these take human, monetary and time resources. It is a challenging road we have chosen, but I am confident that we are set up to succeed. I thank you all for the support you have given us over the years. I hope this is useful information and I welcome any comments and suggestions you may have, either on the list or to me privately. Thank you. // richard From robmilne at web.ca Tue Aug 14 05:03:45 2007 From: robmilne at web.ca (robmilne@web.ca) Date: Tue Aug 14 05:14:46 2007 Subject: [Icc-arm] Product News In-Reply-To: <200708141017.l7EAHXTL058581@dragonsgate2.imagecraft.com> References: <200708141017.l7EAHXTL058581@dragonsgate2.imagecraft.com> Message-ID: <61067.66.206.253.144.1187093025.squirrel@flymail.web.net> Hi Richard, I don't envy your position but I do wish the best for your business. As a hobbyist (though aspiring to creating a product) I am averse to maintenance fees yet I will pay for worthy improvements. I definitely plan to upgrade to the new ICC12 if/when a pro version appears. -rob On Tue, August 14, 2007 6:05 am, Richard wrote: > With all the developments going on, sometimes it is hard to keep > track of things. There is also some rumors that we are emphasizing certain > compilers less etc. so hopefully this email will also address some of > those concerns. > > Obviously, we are in the business to make money, I have always > believe that by providing excellent support, a decent development toolset, > plus the low cost factor, that we would be able to make a decent living. I > see no reason to change from that philosophy. ImageCraft is relatively > speaking a small company, but then again, so is the embedded tools market. > A million unit a year gadget may only > need one copy of the compiler for development! This is a challenging > market. There are gazillions devices out there, each with a potential > market of only a few thousand compiler licenses in total at best. With > multiple fishes in the pond, the feeding can get thin indeed. Then you > have brilliant silicon manufacturers who think that it is in their best > interest to have their own software tools, not caring that it is an > effective way to drive away their third party tool vendors. > > So we have to adjust. We have to look at the potential markets and > react, we have to change our development team setup, we have to look ahead > and come up with effective strategies and tactics. Given this light, the > last thing we want to do is to abandon our existing markets. While we > believe the growth markets would likely be the AVR and ARM, there is no > reason not to continue to develop for the HCS12 and MSP430 platforms. > Especially with the new generations of the S12X > and MSP430X devices coming in, the market potential is bigger than ever. > But we need to be smarter. May be we should look into > educational kits with detail examples and an easy to use board bundles. > Perhaps we need to add more companion products such as a > RTOS. May be we need to be more aggressive in making sure users pay > for the annual maintenance.... > > Of course, coming from a techie background, most importantly, we have > to continue to improve on our technologies. The MIO global optimizer is > working well and we have come up with a plan to improve the performance > further. We need to implement features like __far and __flash to support > certain chip features better (paged function under S12 and flash items > under AVR), and we need to deliver the 64 bits FP support. > > And we need to widen the net farther. We are very excited about the > new Parallax Propeller chips. 8 32 bits core on a single chip. While it is > not a microcontroller per se, the chip has a lot of potential. A Propeller > C, which is under development, is potentially huge. > Beyond that, the Atmel AVR32 is a natural target for us, and we have > new resources with Eclipse expertise so we would be able to leverage the > Studio32 platform from day one. Oh, BTW, relating to that, we > will be releasing an AVR Studio plugin for ICCAVR soon and users than can > use one single IDE for the AVR platform. > > All these take human, monetary and time resources. It is a > challenging road we have chosen, but I am confident that we are set up to > succeed. I thank you all for the support you have given us over the years. > I hope this is useful information and I welcome any > comments and suggestions you may have, either on the list or to me > privately. > > Thank you. > > > // richard > > > > _______________________________________________ > Icc-arm mailing list > Icc-arm@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-arm > > From sergiosider at gmail.com Fri Aug 17 06:53:00 2007 From: sergiosider at gmail.com (Sergio Paulo Sider) Date: Fri Aug 17 07:04:39 2007 Subject: [Icc-arm] problem in ICCV7ARM Message-ID: Hi Richard & All, I think I found a problem in the ARM compiler: When you initialize a constant string with more than 253 characters, it's not initialized correctly. The function sizeof() reports the correct size, but strlen returns 0 or sometimes 1. The string itself shows really 0 or 1 characters. I used the following test program (that works. If you add one or more characters to the string, the problem surfaces): (obs: unsing 7.07A version, but 7.07 had the same problem). #include const char texto[] = "1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890" "1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890" "12345678901234567890123456789012345678901234567890123"; void main(void) { while (1) { if ((strlen(texto)+1) == sizeof(texto)) { //ok } } } PS. I did not find the 7.07A version on the site Thanks, Sergio. From russell.bull at harbourmarine.com Sun Aug 19 17:44:41 2007 From: russell.bull at harbourmarine.com (Russell Bull) Date: Sun Aug 19 17:59:18 2007 Subject: [Icc-arm] problem in ICCV7ARM Message-ID: Gentlemen, I found a small inconsistancy with the declaration of int putchar(int ch) (as referred to in the help file), it is declared in STDIO.H as int putchar(char). Small issue, easy to fix but had me scratching my head a little when the compiler was complaining! Russell Bull Senior Instrumentation Engineer Harbour & Marine Engineering Virginia Park, 9 South Drive, 236 East Boundary Road, East Bentleigh, Melbourne, VIC 3165. Australia Tel: + 61 (0) 3 9575 9999 Fax: + 61 (0) 3 9575 9950 Direct email: russell.bull@harbourmarine.com Web: www.harbourmarine.com Trelleborg Marine Systems This e-mail and any attachments with it are confidential, may be subject to copyright and are intended solely for the use of the addressee. If you are not the intended recipient, you must not copy, retain or distribute or take any action in reliance on it. If you have received this e-mail in error, please notify us and destroy the original transmission. -----Original Message----- From: icc-arm-bounces@imagecraft.com [mailto:icc-arm-bounces@imagecraft.com] On Behalf Of Sergio Paulo Sider Sent: Friday, 17 August 2007 11:53 PM To: Discussion list for ICCV7 for ARM users Subject: [Icc-arm] problem in ICCV7ARM Hi Richard & All, I think I found a problem in the ARM compiler: When you initialize a constant string with more than 253 characters, it's not initialized correctly. The function sizeof() reports the correct size, but strlen returns 0 or sometimes 1. The string itself shows really 0 or 1 characters. I used the following test program (that works. If you add one or more characters to the string, the problem surfaces): (obs: unsing 7.07A version, but 7.07 had the same problem). #include const char texto[] = "12345678901234567890123456789012345678901234567890123456789012345678901 23456789012345678901234567890" "12345678901234567890123456789012345678901234567890123456789012345678901 23456789012345678901234567890" "12345678901234567890123456789012345678901234567890123"; void main(void) { while (1) { if ((strlen(texto)+1) == sizeof(texto)) { //ok } } } PS. I did not find the 7.07A version on the site Thanks, Sergio. _______________________________________________ Icc-arm mailing list Icc-arm@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-arm From richard at imagecraft.com Wed Aug 22 02:27:53 2007 From: richard at imagecraft.com (Richard) Date: Wed Aug 22 02:39:30 2007 Subject: [Icc-arm] ARM compiler 7.08 Beta0 Message-ID: <200708220939.l7M9dTF7079262@dragonsgate2.imagecraft.com> http://www.imagecraft.com/pub/iccv7arm_v708_beta0.exe Readme excerpt: 7.08 Compiler - Added #pragma fiq_handler func1 func2 ... These behave just like interrupt handlers except that they do not save and restore R8-R12 - Fixed a bug under Thumb mode where the compiler was emitting "add R?,#0" forever. Asm/Linker etc. - DCB directive with more than 253 characters (e.g. C char array initialization) was not processed correctly by the assembler. - First release of ELF native asm and linker. The assembler is now called iasarm-elf.exe and the linker is ilinkarm-elf.exe. DBG2Dwarf.exe is no longer needed to generate debug file. Currently some flash space is used for the extended debug info. This will be eliminated later. // richard On-line orders, support, and listservers available on web site. [ For technical support on ImageCraft products, please include all previous replies in your msgs. ] From genna at atsi-tester.com Wed Aug 29 09:04:32 2007 From: genna at atsi-tester.com (Gennadiy Kiryukhin) Date: Wed Aug 29 09:15:12 2007 Subject: [Icc-arm] FIQ problems in 7.08 Message-ID: <46D59910.8000201@atsi-tester.com> I am running 7.08 beta for LPC21xx micro. I have defined an FIQ handler as #pragma fiq_handler rx_bit and an IRQ handler is defined as #pragma interrupt_handler tx_bit. If I enable the interrupts using __ENABLE_FIQ_AND_IRQ_INTERRUPTS() my program just hangs. The FIQ does not seem to be called. However, if I use __ENABLE_INTERRUPT(), the code seems to work except the FIQ as expected. Any reason why? Thanks, Gennadiy From brucepride at prideembedded.com Wed Aug 29 10:42:30 2007 From: brucepride at prideembedded.com (Bruce M. Pride) Date: Wed Aug 29 10:54:36 2007 Subject: [Icc-arm] FIQ problems in 7.08 Message-ID: <20070829104230.6ad35664bad26f46d3fc32d9a902836c.3f08282f35.wbe@email.secureserver.net> An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-arm/attachments/20070829/815979b5/attachment.html From genna at atsi-tester.com Thu Aug 30 13:56:05 2007 From: genna at atsi-tester.com (Gennadiy Kiryukhin) Date: Thu Aug 30 14:06:46 2007 Subject: [Icc-arm] FIQ problems in 7.08 In-Reply-To: <20070829104230.6ad35664bad26f46d3fc32d9a902836c.3f08282f35.wbe@email.secureserver.net> References: <20070829104230.6ad35664bad26f46d3fc32d9a902836c.3f08282f35.wbe@email.secureserver.net> Message-ID: <46D72EE5.6030008@atsi-tester.com> That worked. Thanks. I knew it had to do with the start-up file since the default file did not have the proper command at 0x0000001C adddress, but I was not sure how to change it. I would like to reduce the interrupt latency even more. Is there any way I can force my FIQ to be placed at address 0x0000001C? To Richard, I also noticed that, FIQ is still saving some registers, even though there are R8_fiq through R12_fiq allocated specifically for the FIQ function. Would be nice to have the compiler to use those registers first and add "save registers" commands only when more registers are needed. If I understand correctly, LR would need to be saved only when FIQ calls other functions. Regards, Gennadiy Bruce M. Pride wrote: > Hi Gennadiy, > > I have implemented an FIQ handler with ICCARM for the LPC2103 based > iARM-2103 board. > > Feel free to take a look at the FIQ demo project found here: > http://mysite.verizon.net/vzeo0six/id23.html > > Regards, > > Bruce P. > > -------- Original Message -------- > Subject: [Icc-arm] FIQ problems in 7.08 > From: Gennadiy Kiryukhin > Date: Wed, August 29, 2007 12:04 pm > To: icc-arm@imagecraft.com > > I am running 7.08 beta for LPC21xx micro. > I have defined an FIQ handler as #pragma fiq_handler rx_bit > and an IRQ handler is defined as #pragma interrupt_handler tx_bit. > > If I enable the interrupts using __ENABLE_FIQ_AND_IRQ_INTERRUPTS() my > program just hangs. The FIQ does not seem to be called. However, if I > use __ENABLE_INTERRUPT(), the code seems to work except the FIQ as > expected. Any reason why? > > Thanks, > Gennadiy > > _______________________________________________ > Icc-arm mailing list > Icc-arm@imagecraft.com ?type=replyall&folder=INBOX&uid=4934#Compose> > http://dragonsgate.net/mailman/listinfo/icc-arm > > > ------------------------------------------------------------------------ > > _______________________________________________ > Icc-arm mailing list > Icc-arm@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-arm From BrucePride at PridEEmbedded.com Thu Aug 30 18:59:49 2007 From: BrucePride at PridEEmbedded.com (Bruce M. Pride) Date: Thu Aug 30 19:10:32 2007 Subject: [Icc-arm] FIQ problems in 7.08 References: <20070829104230.6ad35664bad26f46d3fc32d9a902836c.3f08282f35.wbe@email.secureserver.net> <46D72EE5.6030008@atsi-tester.com> Message-ID: <01f101c7eb72$9d5bb2a0$1401a8c0@PrideDesktop> No problem Gennadiy, glad it helped. I spent a lot of time on that demo project for the iARM-2103 board. If you are looking to reduce interrupt latency, then you could write an assembly language interrupt handler starting right at 0x0000001C, which is where I had LDR PC,FIQ_Handler_addr. Another option might be to call your C function, but optimize the FIQ code yourself. I agree that the FIQ doesn't need the same housekeeping as an IRQ, so maybe you or Richard can refine that. That would be a great optimization for the next ICCARM update! :>) I'm very interested in the outcome of this, so please let the group know how things turn out. Thanks and Best Regards, Bruce P. ----- Original Message ----- From: "Gennadiy Kiryukhin" To: "Discussion list for ICCV7 for ARM users" Sent: Thursday, August 30, 2007 4:56 PM Subject: Re: [Icc-arm] FIQ problems in 7.08 > That worked. Thanks. I knew it had to do with the start-up file since > the default file did not have the proper command at 0x0000001C adddress, > but I was not sure how to change it. > > I would like to reduce the interrupt latency even more. Is there any way > I can force my FIQ to be placed at address 0x0000001C? > > > To Richard, > > I also noticed that, FIQ is still saving some registers, even though > there are R8_fiq through R12_fiq allocated specifically for the FIQ > function. Would be nice to have the compiler to use those registers > first and add "save registers" commands only when more registers are > needed. If I understand correctly, LR would need to be saved only when > FIQ calls other functions. > > > Regards, > > Gennadiy > > Bruce M. Pride wrote: > > Hi Gennadiy, > > > > I have implemented an FIQ handler with ICCARM for the LPC2103 based > > iARM-2103 board. > > > > Feel free to take a look at the FIQ demo project found here: > > http://mysite.verizon.net/vzeo0six/id23.html > > > > Regards, > > > > Bruce P. > > > > -------- Original Message -------- > > Subject: [Icc-arm] FIQ problems in 7.08 > > From: Gennadiy Kiryukhin > > Date: Wed, August 29, 2007 12:04 pm > > To: icc-arm@imagecraft.com > > > > I am running 7.08 beta for LPC21xx micro. > > I have defined an FIQ handler as #pragma fiq_handler rx_bit > > and an IRQ handler is defined as #pragma interrupt_handler tx_bit. > > > > If I enable the interrupts using __ENABLE_FIQ_AND_IRQ_INTERRUPTS() my > > program just hangs. The FIQ does not seem to be called. However, if I > > use __ENABLE_INTERRUPT(), the code seems to work except the FIQ as > > expected. Any reason why? > > > > Thanks, > > Gennadiy > > > > _______________________________________________ > > Icc-arm mailing list > > Icc-arm@imagecraft.com > ?type=replyall&folder=INBOX&uid=4934#Compose> > > http://dragonsgate.net/mailman/listinfo/icc-arm > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Icc-arm mailing list > > Icc-arm@imagecraft.com > > http://dragonsgate.net/mailman/listinfo/icc-arm > > _______________________________________________ > Icc-arm mailing list > Icc-arm@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-arm > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-arm/attachments/20070830/44bbbadd/attachment.html From genna at atsi-tester.com Fri Aug 31 06:59:40 2007 From: genna at atsi-tester.com (Gennadiy Kiryukhin) Date: Fri Aug 31 07:10:31 2007 Subject: [Icc-arm] FIQ problems in 7.08 In-Reply-To: <01f101c7eb72$9d5bb2a0$1401a8c0@PrideDesktop> References: <20070829104230.6ad35664bad26f46d3fc32d9a902836c.3f08282f35.wbe@email.secureserver.net> <46D72EE5.6030008@atsi-tester.com> <01f101c7eb72$9d5bb2a0$1401a8c0@PrideDesktop> Message-ID: <46D81ECC.3080707@atsi-tester.com> I though of taking the output .s file from compiler and pasting the FIQ code directly into the startup file. I would also have to manually replace all of R0-R4 with R8-R12. That would eliminate the need to write the FIQ in assembly language, and yet would give me the ability to control the code at the low level. Does anybody know of a way to tell the compiler not to use certain CPU registers for a specific a function? I could block R0-R7 and force the compiler to use the FIQ registers. Gennadiy Bruce M. Pride wrote: > No problem Gennadiy, glad it helped. I spent a lot of time on that demo > project for the iARM-2103 board. > > If you are looking to reduce interrupt latency, then you could write an > assembly language interrupt handler starting right at 0x0000001C, which > is where I had LDR PC,FIQ_Handler_addr. > > Another option might be to call your C function, but optimize the FIQ > code yourself. I agree that the FIQ doesn't need the same housekeeping > as an IRQ, so maybe you or Richard can refine that. That would be a > great optimization for the next ICCARM update! :>) > > I'm very interested in the outcome of this, so please let the group know > how things turn out. > > Thanks and Best Regards, > > Bruce P. > > ----- Original Message ----- > From: "Gennadiy Kiryukhin" > > To: "Discussion list for ICCV7 for ARM users" > > Sent: Thursday, August 30, 2007 4:56 PM > Subject: Re: [Icc-arm] FIQ problems in 7.08 > > > That worked. Thanks. I knew it had to do with the start-up file since > > the default file did not have the proper command at 0x0000001C adddress, > > but I was not sure how to change it. > > > > I would like to reduce the interrupt latency even more. Is there any way > > I can force my FIQ to be placed at address 0x0000001C? > > > > > > To Richard, > > > > I also noticed that, FIQ is still saving some registers, even though > > there are R8_fiq through R12_fiq allocated specifically for the FIQ > > function. Would be nice to have the compiler to use those registers > > first and add "save registers" commands only when more registers are > > needed. If I understand correctly, LR would need to be saved only when > > FIQ calls other functions. > > > > > > Regards, > > > > Gennadiy > > > > Bruce M. Pride wrote: > > > Hi Gennadiy, > > > > > > I have implemented an FIQ handler with ICCARM for the LPC2103 based > > > iARM-2103 board. > > > > > > Feel free to take a look at the FIQ demo project found here: > > > http://mysite.verizon.net/vzeo0six/id23.html > > > > > > Regards, > > > > > > Bruce P. > > > > > > -------- Original Message -------- > > > Subject: [Icc-arm] FIQ problems in 7.08 > > > From: Gennadiy Kiryukhin > > > > Date: Wed, August 29, 2007 12:04 pm > > > To: icc-arm@imagecraft.com > > > > > > I am running 7.08 beta for LPC21xx micro. > > > I have defined an FIQ handler as #pragma fiq_handler rx_bit > > > and an IRQ handler is defined as #pragma interrupt_handler tx_bit. > > > > > > If I enable the interrupts using > __ENABLE_FIQ_AND_IRQ_INTERRUPTS() my > > > program just hangs. The FIQ does not seem to be called. > However, if I > > > use __ENABLE_INTERRUPT(), the code seems to work except the FIQ as > > > expected. Any reason why? > > > > > > Thanks, > > > Gennadiy > > > > > > _______________________________________________ > > > Icc-arm mailing list > > > Icc-arm@imagecraft.com > > > ?type=replyall&folder=INBOX&uid=4934#Compose> > > > http://dragonsgate.net/mailman/listinfo/icc-arm > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > > Icc-arm mailing list > > > Icc-arm@imagecraft.com > > > http://dragonsgate.net/mailman/listinfo/icc-arm > > > > _______________________________________________ > > Icc-arm mailing list > > Icc-arm@imagecraft.com > > http://dragonsgate.net/mailman/listinfo/icc-arm > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Icc-arm mailing list > Icc-arm@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-arm From genna at atsi-tester.com Fri Aug 31 15:17:29 2007 From: genna at atsi-tester.com (Gennadiy Kiryukhin) Date: Fri Aug 31 15:28:22 2007 Subject: [Icc-arm] FIQ and custom startup file In-Reply-To: <46D81ECC.3080707@atsi-tester.com> References: <20070829104230.6ad35664bad26f46d3fc32d9a902836c.3f08282f35.wbe@email.secureserver.net> <46D72EE5.6030008@atsi-tester.com> <01f101c7eb72$9d5bb2a0$1401a8c0@PrideDesktop> <46D81ECC.3080707@atsi-tester.com> Message-ID: <46D89379.70801@atsi-tester.com> I have added some code to the my custom startup file (s file). When trying to compile it, I get error: Unable to fit C$$init section into memory. What is C$$init and how does it affect it? Where does C$$code start? Can I define my own "area" and place it at 0x00001C? How? Where can I get more information on how to write a startup file? I am trying to place my FIQ at that address. Here is what I have discovered so far. I have not tested the code, but it compiles without errors. IMPORT _main AREA "C$$init",CODE,READONLY // exception vector section LDR PC,cstart_addr // Reset SUB PC,PC,#8 // Undefined instruction SUB PC,PC,#8 // Software interrupt cstart_addr: DCD _cstart // In place of prefetch data abort SUB PC,PC,#8 // Data abort SUB PC,PC,#8 // Not used LDR PC,[PC,#-0xFF0] // IRQ Vector AREA "C$$code",CODE,READONLY _my_fiq_processor: ; FIQ code is placed here // the rest of the file without change follows... I had to use the prefetch data abort vector for storing the address of _cstart label. The reason for this is if I tried to place the "cstart_addr ..." after the FIQ code, the compiler would give me an error because the offset was too big. Don't see the reason for the error since my FIQ was under 1K in size and LDR PC, xxx allows the address to be within 4K limit relative to the current command. There is one problem with that. I am not sure where 'C$$code' area starts. If I take that line out and make my FIQ to be a part of C$$init, the compiler says: !E Unable to fit C$$init section into memory Thanks, Gennadiy From sergiosider at gmail.com Fri Aug 31 15:43:47 2007 From: sergiosider at gmail.com (Sergio Paulo Sider) Date: Fri Aug 31 15:55:50 2007 Subject: [Icc-arm] FIQ and custom startup file In-Reply-To: <46D89379.70801@atsi-tester.com> References: <20070829104230.6ad35664bad26f46d3fc32d9a902836c.3f08282f35.wbe@email.secureserver.net> <46D72EE5.6030008@atsi-tester.com> <01f101c7eb72$9d5bb2a0$1401a8c0@PrideDesktop> <46D81ECC.3080707@atsi-tester.com> <46D89379.70801@atsi-tester.com> Message-ID: Hi, I had similar problems with the beta version (7.08) and had to roll-back to 7.07A. I think Richard is still fixing some problems. Are you using the last beta version ? Regards, Sergio. On 8/31/07, Gennadiy Kiryukhin wrote: > I have added some code to the my custom startup file (s file). When > trying to compile it, I get error: > Unable to fit C$$init section into memory. > > What is C$$init and how does it affect it? > Where does C$$code start? > Can I define my own "area" and place it at 0x00001C? How? > Where can I get more information on how to write a startup file? > > I am trying to place my FIQ at that address. > > Here is what I have discovered so far. I have not tested the code, but > it compiles without errors. > > IMPORT _main > AREA "C$$init",CODE,READONLY > > // exception vector section > LDR PC,cstart_addr // Reset > SUB PC,PC,#8 // Undefined instruction > SUB PC,PC,#8 // Software interrupt > cstart_addr: DCD _cstart // In place of prefetch data abort > SUB PC,PC,#8 // Data abort > SUB PC,PC,#8 // Not used > LDR PC,[PC,#-0xFF0] // IRQ Vector > > AREA "C$$code",CODE,READONLY > _my_fiq_processor: > ; FIQ code is placed here > > // the rest of the file without change follows... > > > I had to use the prefetch data abort vector for storing the address of > _cstart label. The reason for this is if I tried to place the > "cstart_addr ..." after the FIQ code, the compiler would give me an > error because the offset was too big. Don't see the reason for the error > since my FIQ was under 1K in size and LDR PC, xxx allows the address to > be within 4K limit relative to the current command. > > There is one problem with that. I am not sure where 'C$$code' area > starts. If I take that line out and make my FIQ to be a part of C$$init, > the compiler says: > !E Unable to fit C$$init section into memory > > > Thanks, > > Gennadiy > > _______________________________________________ > Icc-arm mailing list > Icc-arm@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-arm >