From richard at imagecraft.com Wed Jan 10 19:06:53 2007 From: richard at imagecraft.com (Richard) Date: Wed Jan 10 19:14:19 2007 Subject: [Icc-430] V7.04 released Message-ID: <6.1.0.6.2.20070110190451.09b4ed18@192.168.100.42> We are transition the website in the next few days. The new site is currently called http://stage.imagecraft.com and you can d/l the latest demo from that site as well. V7.04 - Jan 11th 2007 Minor licensing changes IDE - Some of the F2xxx devices have the incorrect SRAM sizes - Added all latest devices Header Files - New header files from TI Linker - Static variables and functions now appear in the .mp MAP file Library - Much faster floating point divide function, courtesy of Jon Kirwan. // 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 bubbles at speakeasy.net Thu Jan 11 03:13:42 2007 From: bubbles at speakeasy.net (Tom Digby) Date: Thu Jan 11 03:20:44 2007 Subject: New Web Site, was Re: [Icc-430] V7.04 released In-Reply-To: <6.1.0.6.2.20070110190451.09b4ed18@192.168.100.42> References: <6.1.0.6.2.20070110190451.09b4ed18@192.168.100.42> Message-ID: <45A61BE6.2090802@speakeasy.net> The old site has a link to your artistic side. I don't see that on the new version, although I could have missed it. Are you going to include it? Richard wrote: > We are transition the website in the next few days. The new site is > currently called http://stage.imagecraft.com and you can d/l the latest > demo from that site as well. > > V7.04 - Jan 11th 2007 > Minor licensing changes > IDE > - Some of the F2xxx devices have the incorrect SRAM sizes > - Added all latest devices > Header Files > - New header files from TI > Linker > - Static variables and functions now appear in the .mp MAP file > Library > - Much faster floating point divide function, courtesy of Jon Kirwan. > > > // 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. ] > _______________________________________________ > Icc-430 mailing list > Icc-430@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-430 > > -- Tom Digby http://www.well.com/~bubbles/ From jdurand at interstellar.com Thu Jan 11 09:18:01 2007 From: jdurand at interstellar.com (Jerry Durand) Date: Thu Jan 11 09:25:20 2007 Subject: [Icc-430] V7.04 released In-Reply-To: <6.1.0.6.2.20070110190451.09b4ed18@192.168.100.42> References: <6.1.0.6.2.20070110190451.09b4ed18@192.168.100.42> Message-ID: <7.0.1.0.0.20070111091644.01efcec8@interstellar.com> At 07:06 PM 1/10/2007, Richard wrote: >We are transition the website in the next few days. The new site is >currently called http://stage.imagecraft.com and you can d/l the >latest demo from that site as well. "Failed to download file" I guess it's not there yet. I assume 7.04 will update 7.03 Pro with no problem, as in the past. -- Jerry Durand, Durand Interstellar, Inc. www.interstellar.com tel: +1 408 356-3886, USA toll free: 1 866 356-3886 Skype: jerrydurand From jdurand at interstellar.com Thu Jan 11 09:28:02 2007 From: jdurand at interstellar.com (Jerry Durand) Date: Thu Jan 11 09:36:06 2007 Subject: [Icc-430] V7.04 released Message-ID: <7.0.1.0.0.20070111091856.01ed9ff8@interstellar.com> I notice the flyer says it supports long file names. With spaces? With spaces in the folder names? example: e:\client files\pain in neck1\job 53\interrupt handler.c I haven't tried it with ICC430 because I haven't seen a system since my Apple ][ that could properly handle long file names with spaces. I now never use spaces, even though they are supposed to be legal. -- Jerry Durand, Durand Interstellar, Inc. www.interstellar.com tel: +1 408 356-3886, USA toll free: 1 866 356-3886 Skype: jerrydurand From richard-lists at imagecraft.com Thu Jan 11 13:57:53 2007 From: richard-lists at imagecraft.com (Richard) Date: Thu Jan 11 14:05:22 2007 Subject: [Icc-430] V7.04 released In-Reply-To: <7.0.1.0.0.20070111091644.01efcec8@interstellar.com> References: <6.1.0.6.2.20070110190451.09b4ed18@192.168.100.42> <7.0.1.0.0.20070111091644.01efcec8@interstellar.com> Message-ID: <6.1.0.6.2.20070111135719.097131e8@192.168.100.42> Use this link during the transition: ftp://ftp.imagecraft.com/pub/pub/iccv7430_demo.exe At 09:18 AM 1/11/2007, Jerry Durand wrote: >At 07:06 PM 1/10/2007, Richard wrote: >>We are transition the website in the next few days. The new site is >>currently called http://stage.imagecraft.com and you can d/l the latest >>demo from that site as well. > >"Failed to download file" I guess it's not there yet. > >I assume 7.04 will update 7.03 Pro with no problem, as in the past. Yup. // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From creator at flyinghouse.com Thu Jan 11 18:48:26 2007 From: creator at flyinghouse.com (creator@flyinghouse.com) Date: Thu Jan 11 18:55:34 2007 Subject: [Icc-430] NoICE will not load V7.04 .dbg files Message-ID: <380-22007151224826773@M2W040.mail2web.com> Greetings, The subject line says it all... The error window says: "The file contains information of a version not supported by NoICE" I can however still load the HEX file with NoICE, but that does not help with symbolic debugging. Any suggestions? Thanks, -Dann ================================================================ Dann McCreary http://flyinghouse.com creator-at-flyinghouse.com SubArcSecond Tracking Accuracy! -- Visit http://subarcsec.com Read The Bills Act http://www.downsizedc.org/read_the_laws.shtml ================================================================ "The heavens are telling of the glory of God; and their expanse is declaring the work of His hands" - Psalm 19:1 (NASB) ================================================================ -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ . From richard-lists at imagecraft.com Thu Jan 11 19:10:09 2007 From: richard-lists at imagecraft.com (Richard) Date: Thu Jan 11 19:17:39 2007 Subject: [Icc-430] NoICE will not load V7.04 .dbg files In-Reply-To: <380-22007151224826773@M2W040.mail2web.com> References: <380-22007151224826773@M2W040.mail2web.com> Message-ID: <6.1.0.6.2.20070111190935.09aeb7b8@192.168.100.42> Which NoICE do you have? If not the latest, d/l and install it at www.noicedebugger.com At 06:48 PM 1/11/2007, creator@flyinghouse.com wrote: >Greetings, > >The subject line says it all... The error window says: > > "The file contains information of a version not supported by NoICE" > >I can however still load the HEX file with NoICE, but that does >not help with symbolic debugging. > >Any suggestions? > >Thanks, > >-Dann // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From creator at flyinghouse.com Thu Jan 11 19:41:30 2007 From: creator at flyinghouse.com (creator@flyinghouse.com) Date: Thu Jan 11 19:48:49 2007 Subject: [Icc-430] NoICE will not load V7.04 .dbg files - Thanks! Message-ID: <380-22007151234130399@M2W021.mail2web.com> Hi Richard, > Which NoICE do you have? If not the latest, d/l and install > it at www.noicedebugger.com Thanks, that did it; I had not been hasty to check and download at NoICE because John had created a "special" for me a few months back when I couldn't use Spy-Bi-Wire with NoICE; apparently he may now have incorporated those fixes into the release version. Thanks for the pointer, -Dann ================================================================ Dann McCreary http://flyinghouse.com creator-at-flyinghouse.com SubArcSecond Tracking Accuracy! -- Visit http://subarcsec.com Read The Bills Act http://www.downsizedc.org/read_the_laws.shtml ================================================================ "The heavens are telling of the glory of God; and their expanse is declaring the work of His hands" - Psalm 19:1 (NASB) ================================================================ At 06:48 PM 1/11/2007, creator@flyinghouse.com wrote: > Greetings, > > The subject line says it all... The error window says: > > "The file contains information of a version not supported by NoICE" > > I can however still load the HEX file with NoICE, but that does > not help with symbolic debugging. > > Any suggestions? > > Thanks, > > -Dann -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ . From richard at imagecraft.com Sat Jan 20 15:12:36 2007 From: richard at imagecraft.com (Richard) Date: Sat Jan 20 15:20:39 2007 Subject: [Icc-430] new website is alive Message-ID: <6.1.0.6.2.20070120140745.08c8cd28@192.168.100.42> It may take up to 24 hours for the DNS change to propagate, but the new imagecraft website is live! Go visit www.imagecraft.com and let us know if something is amiss. Thanks. // richard From jdurand at interstellar.com Sun Jan 21 15:15:33 2007 From: jdurand at interstellar.com (Jerry Durand) Date: Sun Jan 21 15:23:26 2007 Subject: [Icc-430] Security Fuses Message-ID: <7.0.1.0.0.20070121151015.01f17020@interstellar.com> Are there any utilities yet that will blow the security fuse using the MSP-FET430UIF? IAR Kickstart says it will do it, but the debugger doesn't want to start unless I have a fully compiled project to debug or at least a debug file compatible with them (ICC430 files aren't). I REALLY don't want to buy yet another programming adaptor (that would make four) just to do this. For production quantities, it isn't a problem since the chip vendor can do it. I need to do this on occasion for custom/prototype devices. -- Jerry Durand, Durand Interstellar, Inc. www.interstellar.com tel: +1 408 356-3886, USA toll free: 1 866 356-3886 Skype: jerrydurand From richard-lists at imagecraft.com Sun Jan 21 15:42:19 2007 From: richard-lists at imagecraft.com (Richard) Date: Sun Jan 21 15:50:24 2007 Subject: [Icc-430] Security Fuses In-Reply-To: <7.0.1.0.0.20070121151015.01f17020@interstellar.com> References: <7.0.1.0.0.20070121151015.01f17020@interstellar.com> Message-ID: <6.1.0.6.2.20070121153918.08927a50@192.168.100.42> You probably know this, but just in case - the latest NoICE and the ICC430 builtin downloader supports it but only with the USB JTag. I suspect it may be a requirement from the TI.DLL and MSP430.DLL? But I am not sure. At 03:15 PM 1/21/2007, Jerry Durand wrote: >Are there any utilities yet that will blow the security fuse using the >MSP-FET430UIF? > >IAR Kickstart says it will do it, but the debugger doesn't want to start >unless I have a fully compiled project to debug or at least a debug file >compatible with them (ICC430 files aren't). > >I REALLY don't want to buy yet another programming adaptor (that would >make four) just to do this. > >For production quantities, it isn't a problem since the chip vendor can do >it. I need to do this on occasion for custom/prototype devices. > // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From jdurand at interstellar.com Sun Jan 21 16:05:01 2007 From: jdurand at interstellar.com (Jerry Durand) Date: Sun Jan 21 16:13:02 2007 Subject: [Icc-430] Security Fuses In-Reply-To: <6.1.0.6.2.20070121153918.08927a50@192.168.100.42> References: <7.0.1.0.0.20070121151015.01f17020@interstellar.com> <6.1.0.6.2.20070121153918.08927a50@192.168.100.42> Message-ID: <7.0.1.0.0.20070121160413.01f3a9a0@interstellar.com> At 03:42 PM 1/21/2007, Richard wrote: >You probably know this, but just in case - the latest NoICE and the >ICC430 builtin downloader supports it but only with the USB JTag. I >suspect it may be a requirement from the TI.DLL and MSP430.DLL? But >I am not sure. I didn't know that, any idea how you say "do it"? I haven't (so far) found anything in the documentation about it. -- Jerry Durand, Durand Interstellar, Inc. www.interstellar.com tel: +1 408 356-3886, USA toll free: 1 866 356-3886 Skype: jerrydurand From richard-lists at imagecraft.com Sun Jan 21 16:29:21 2007 From: richard-lists at imagecraft.com (Richard) Date: Sun Jan 21 16:37:25 2007 Subject: [Icc-430] Security Fuses In-Reply-To: <7.0.1.0.0.20070121160413.01f3a9a0@interstellar.com> References: <7.0.1.0.0.20070121151015.01f17020@interstellar.com> <6.1.0.6.2.20070121153918.08927a50@192.168.100.42> <7.0.1.0.0.20070121160413.01f3a9a0@interstellar.com> Message-ID: <6.1.0.6.2.20070121162631.0893b008@192.168.100.42> At 04:05 PM 1/21/2007, Jerry Durand wrote: >At 03:42 PM 1/21/2007, Richard wrote: >>You probably know this, but just in case - the latest NoICE and the >>ICC430 builtin downloader supports it but only with the USB JTag. I >>suspect it may be a requirement from the TI.DLL and MSP430.DLL? But I am >>not sure. > >I didn't know that, any idea how you say "do it"? I haven't (so far) >found anything in the documentation about it. > Sorry I forgot, not with the IDE builtin function. John of NoICE says it's too dangerous :-) Use the command line icc430dl Just typing the command will give you the argument name // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From richard at imagecraft.com Sun Jan 21 16:34:52 2007 From: richard at imagecraft.com (Richard) Date: Sun Jan 21 16:42:57 2007 Subject: [Icc-430] V7.05 BETA0 Message-ID: <6.1.0.6.2.20070121163248.0893d7b0@192.168.100.42> http://www.imagecraft.com/pub/iccv7430_v705_beta0.exe V7.05 Compiler - Further improvement to 32 bit == != code (thanks to Kirk Bailey) - Interface to the 32 bit internal functions for longs and floating point now use R12/R13 in addition to R14/R15 for argument passing, resulting in smaller and faster code. Library - faster structure copying and str*/mem* functions TI DLL for flash programming and debugging - upgraded to the latest 2.8.1 of the MSP430.DLL and HIL.DLL // 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 jdurand at interstellar.com Sun Jan 21 17:38:15 2007 From: jdurand at interstellar.com (Jerry Durand) Date: Sun Jan 21 17:46:00 2007 Subject: [Icc-430] Security Fuses In-Reply-To: <6.1.0.6.2.20070121162631.0893b008@192.168.100.42> References: <7.0.1.0.0.20070121151015.01f17020@interstellar.com> <6.1.0.6.2.20070121153918.08927a50@192.168.100.42> <7.0.1.0.0.20070121160413.01f3a9a0@interstellar.com> <6.1.0.6.2.20070121162631.0893b008@192.168.100.42> Message-ID: <7.0.1.0.0.20070121173802.01f0ee50@interstellar.com> At 04:29 PM 1/21/2007, Richard wrote: >Sorry I forgot, not with the IDE builtin function. John of NoICE >says it's too dangerous :-) Use the command line >icc430dl > >Just typing the command will give you the argument name AH, thanks. -- Jerry Durand, Durand Interstellar, Inc. www.interstellar.com tel: +1 408 356-3886, USA toll free: 1 866 356-3886 Skype: jerrydurand From kris at abbey.co.nz Tue Jan 23 12:27:14 2007 From: kris at abbey.co.nz (Kris Heidenstrom) Date: Tue Jan 23 12:34:30 2007 Subject: [Icc-430] Interrupt handler wrapper preserves R8,9 - repost Message-ID: <00da01c73f2c$de4c4600$1917a8c0@KH> Hi, I'm reposting this from 2006-11-30 because no one replied then. I've confirmed the issue still exists with V7.05 beta0. The compiler-generated interrupt handler wrapper code preserves R8 and R9 as well as R10~15. I don't think it should. >From "Assembly Interface and Calling Conventions" in the online help: ---------------------------------------- Preserved Registers R4~9 These registers are called preserved registers, since their contents are unchanged by a function call. Local variables are assigned to these registers by the compiler. Volatile Registers R10~15 Can be used in a function without being saved or restored. These registers are called volatile registers, since their contents may be changed by a function call. Interrupt Handlers If you write a handler in assembly and if it calls normal C functions, then the assembly handler must save and restore the volatile registers, since normal C functions do not preserve them. ---------------------------------------- I think the descriptions in the help are right and up-to-date, and I think the interrupt handler wrapper is out-of-date. I wrote my own wrapper in assembler, which does not preserve R8 and R9, and everything seemed to work OK. Am I missing something here? Kris -- Kris Heidenstrom Embedded systems designer / programmer kris@abbey.co.nz Abbey Systems Ltd - Telemetry Specialists Wellington NEW ZEALAND Voice +64-4-385-6611 Fax +64-4-385-6848 From bailey at peak.org Tue Jan 23 14:18:17 2007 From: bailey at peak.org (bailey@peak.org) Date: Tue Jan 23 14:25:25 2007 Subject: [Icc-430] Interrupt handler wrapper preserves R8,9 - repost In-Reply-To: <00da01c73f2c$de4c4600$1917a8c0@KH> References: <00da01c73f2c$de4c4600$1917a8c0@KH> Message-ID: <1064.69.59.200.77.1169590697.squirrel@webmail.peak.org> Kris et al, This makes sense to me. I was surprised by the save/restore overhead when I was debugging some really light-weight routines, but I never dug into the details. Unless there is a problem with this that Richard knows about, I would strongly support making this change. Kirk Bailey bailey@peak.org > Hi, > > I'm reposting this from 2006-11-30 because > no one replied then. I've confirmed the issue > still exists with V7.05 beta0. > > The compiler-generated interrupt handler wrapper > code preserves R8 and R9 as well as R10~15. > I don't think it should. > >>From "Assembly Interface and Calling > Conventions" in the online help: > ---------------------------------------- > Preserved Registers R4~9 > These registers are called preserved registers, > since their contents are unchanged by a function > call. Local variables are assigned to these registers > by the compiler. > > Volatile Registers R10~15 > Can be used in a function without being saved or > restored. These registers are called volatile registers, > since their contents may be changed by a function > call. > > Interrupt Handlers > If you write a handler in assembly and if it calls > normal C functions, then the assembly handler > must save and restore the volatile registers, > since normal C functions do not preserve them. > ---------------------------------------- > > I think the descriptions in the help are right and > up-to-date, and I think the interrupt handler > wrapper is out-of-date. I wrote my own wrapper > in assembler, which does not preserve R8 and > R9, and everything seemed to work OK. > > Am I missing something here? > > Kris > -- > Kris Heidenstrom Embedded systems designer / programmer > kris@abbey.co.nz Abbey Systems Ltd - Telemetry Specialists > Wellington NEW ZEALAND Voice +64-4-385-6611 Fax +64-4-385-6848 > > _______________________________________________ > Icc-430 mailing list > Icc-430@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-430 > From jdurand at interstellar.com Tue Jan 23 14:30:24 2007 From: jdurand at interstellar.com (Jerry Durand) Date: Tue Jan 23 14:37:57 2007 Subject: [Icc-430] Interrupt handler wrapper preserves R8,9 - repost In-Reply-To: <00da01c73f2c$de4c4600$1917a8c0@KH> References: <00da01c73f2c$de4c4600$1917a8c0@KH> Message-ID: <7.0.1.0.0.20070123142733.01fa9960@interstellar.com> At 12:27 PM 1/23/2007, Kris Heidenstrom wrote: >I think the descriptions in the help are right and >up-to-date, and I think the interrupt handler >wrapper is out-of-date. I wrote my own wrapper >in assembler, which does not preserve R8 and >R9, and everything seemed to work OK. >Am I missing something here? Not sure if I understand you. During an interrupt, you have to save EVERYTHING, since there's no telling what you were doing when the interrupt happened. Also, be really careful about calling functions from inside an interrupt, many functions are not re-entrant and if you call them from an interrupt in the middle of some other routine calling them, your program will most probably do some very strange things. -- Jerry Durand, Durand Interstellar, Inc. www.interstellar.com tel: +1 408 356-3886, USA toll free: 1 866 356-3886 Skype: jerrydurand From kris at abbey.co.nz Tue Jan 23 15:16:57 2007 From: kris at abbey.co.nz (Kris Heidenstrom) Date: Tue Jan 23 15:24:05 2007 Subject: [Icc-430] Interrupt handler wrapper preserves R8,9 Message-ID: <001501c73f44$94438f10$1917a8c0@KH> Jerry Durand wrote: KH>>I think the descriptions in the help are right and KH>>up-to-date, and I think the interrupt handler KH>>wrapper is out-of-date. I wrote my own wrapper KH>>in assembler, which does not preserve R8 and KH>>R9, and everything seemed to work OK. KH>>Am I missing something here? JD>Not sure if I understand you. During an interrupt, JD>you have to save EVERYTHING, since there's no JD>telling what you were doing when the interrupt JD>happened. Also, be really careful about calling JD> functions from inside an interrupt, many functions JD>are not re-entrant and if you call them from an JD>interrupt in the middle of some other routine JD>calling them, your program will most probably JD>do some very strange things. You don't have to save everything, only the registers you are going to modify. ICC430 functions preserve R4~9 (that's why they're called "preserved registers" in the help) by pushing them at the start and popping them at the end (if they're used for local variables in the function), so the interrupt handler wrapper doesn't need to preserve them, and doing so is wasteful. It only needs to preserve the registers that will not be preserved by the called function(s), which are R10~15 according to the help and according to the compiler output I've seen. Thanks for the "reentrancy 101", perhaps I shouldn't have asked "am I missing something here" :-) -- Kris Heidenstrom Embedded systems designer / programmer kris@abbey.co.nz Abbey Systems Ltd - Telemetry Specialists Wellington NEW ZEALAND Voice +64-4-385-6611 Fax +64-4-385-6848 From jdurand at interstellar.com Tue Jan 23 16:45:54 2007 From: jdurand at interstellar.com (Jerry Durand) Date: Tue Jan 23 16:53:30 2007 Subject: [Icc-430] Interrupt handler wrapper preserves R8,9 In-Reply-To: <001501c73f44$94438f10$1917a8c0@KH> References: <001501c73f44$94438f10$1917a8c0@KH> Message-ID: <7.0.1.0.0.20070123164103.01f42728@interstellar.com> At 03:16 PM 1/23/2007, Kris Heidenstrom wrote: >You don't have to save everything, only the registers >you are going to modify. That is what I meant, you can't return with anything modified other than perhaps the LPM status. >Thanks for the "reentrancy 101", perhaps I shouldn't >have asked "am I missing something here" :-) When I get up to my neck in work, I may forget the most basic stuff. I just delivered a prototype laser controller programmed in demo mode for a trade show. The client was a month late getting me stuff so I've only had since last week to bring it up (including FPGA code). At this point I may not remember my name. :) Oh, and yesterday a custom plastic enclosure showed up for another client, seems I got the mold design right, everything fits! Busy week. -- Jerry Durand, Durand Interstellar, Inc. www.interstellar.com tel: +1 408 356-3886, USA toll free: 1 866 356-3886 Skype: jerrydurand From kris at abbey.co.nz Tue Jan 23 20:43:10 2007 From: kris at abbey.co.nz (Kris Heidenstrom) Date: Tue Jan 23 20:51:19 2007 Subject: [Icc-430] V7.05 BETA0 - error in handling of longs in div32u/mod32u? References: <6.1.0.6.2.20070121163248.0893d7b0@192.168.100.42> Message-ID: <002a01c73f72$26516a80$1917a8c0@KH> Richard wrote > V7.05 [...] > - Interface to the 32 bit internal functions for longs and > floating > point now use R12/R13 in addition to R14/R15 for argument > passing, > resulting in smaller and faster code. [...] There seems to be a problem with division of longs. I'm not 100% sure of the details, but what I think has happened is this. The canned code block for div32u (also used by mod32u) has not been updated to use R12,13 and is still assuming that one parameter will be passed on the stack. At the end of the canned code block, the code copies the return address from (SP+0) to (SP+4), then adds 4 to SP, then returns. This would be right if there was a 32-bit parameter on the stack, but this parameter is now passed in registers. As a result, some data further up the stack is clobbered, and the MCU may or may not return to somewhere meaningful, depending on the stack usage of the function that invokes div32u/mod32u. I'm not sure whether the canned code for div32u/mod32u comes from a library, or is hard-coded into the compiler, but in either case, I think it needs to be updated to be compatible with this new calling convention. Regards Kris -- Kris Heidenstrom Embedded systems designer / programmer kris@abbey.co.nz Abbey Systems Ltd - Telemetry Specialists Wellington NEW ZEALAND Voice +64-4-385-6611 Fax +64-4-385-6848 From richard-lists at imagecraft.com Tue Jan 23 21:50:11 2007 From: richard-lists at imagecraft.com (Richard) Date: Tue Jan 23 21:57:30 2007 Subject: [Icc-430] V7.05 BETA0 - error in handling of longs in div32u/mod32u? In-Reply-To: <002a01c73f72$26516a80$1917a8c0@KH> References: <6.1.0.6.2.20070121163248.0893d7b0@192.168.100.42> <002a01c73f72$26516a80$1917a8c0@KH> Message-ID: <6.1.0.6.2.20070123214907.08b60868@192.168.100.42> Eh? All the internal routines, including div32u etc have been modified. Do you have a test case showing it's not working? At 08:43 PM 1/23/2007, Kris Heidenstrom wrote: >Richard wrote > > >>V7.05 >[...] >> - Interface to the 32 bit internal functions for longs and floating >> point now use R12/R13 in addition to R14/R15 for argument passing, >> resulting in smaller and faster code. >[...] > >There seems to be a problem with division of longs. I'm not >100% sure of the details, but what I think has happened is this. > >The canned code block for div32u (also used by mod32u) has >not been updated to use R12,13 and is still assuming that one >parameter will be passed on the stack. At the end of the canned >code block, the code copies the return address from (SP+0) to >(SP+4), then adds 4 to SP, then returns. This would be right if >there was a 32-bit parameter on the stack, but this parameter is >now passed in registers. As a result, some data further up the >stack is clobbered, and the MCU may or may not return to >somewhere meaningful, depending on the stack usage of the >function that invokes div32u/mod32u. I'm not sure whether >the canned code for div32u/mod32u comes from a library, or is >hard-coded into the compiler, but in either case, I think it needs >to be updated to be compatible with this new calling convention. > >Regards > >Kris >-- >Kris Heidenstrom Embedded systems designer / programmer >kris@abbey.co.nz Abbey Systems Ltd - Telemetry Specialists >Wellington NEW ZEALAND Voice +64-4-385-6611 Fax +64-4-385-6848 > > >_______________________________________________ >Icc-430 mailing list >Icc-430@imagecraft.com >http://dragonsgate.net/mailman/listinfo/icc-430 // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From bailey at peak.org Tue Jan 23 22:38:50 2007 From: bailey at peak.org (bailey@peak.org) Date: Tue Jan 23 22:45:58 2007 Subject: [Icc-430] V7.05 BETA0 - error in handling of longs in div32u/mod32u? In-Reply-To: <6.1.0.6.2.20070123214907.08b60868@192.168.100.42> References: <6.1.0.6.2.20070121163248.0893d7b0@192.168.100.42> <002a01c73f72$26516a80$1917a8c0@KH> <6.1.0.6.2.20070123214907.08b60868@192.168.100.42> Message-ID: <1565.69.59.200.77.1169620730.squirrel@webmail.peak.org> Any chance you have a mix of modules/libraries built with different compiler versions (and calling conventions)? I had a weird case of this myself not too long ago... Kirk Bailey bailey@peak.org > Eh? All the internal routines, including div32u etc have been modified. Do > you have a test case showing it's not working? > > At 08:43 PM 1/23/2007, Kris Heidenstrom wrote: >>Richard wrote >> >> >>>V7.05 >>[...] >>> - Interface to the 32 bit internal functions for longs and floating >>> point now use R12/R13 in addition to R14/R15 for argument >>> passing, >>> resulting in smaller and faster code. >>[...] >> >>There seems to be a problem with division of longs. I'm not >>100% sure of the details, but what I think has happened is this. >> >>The canned code block for div32u (also used by mod32u) has >>not been updated to use R12,13 and is still assuming that one >>parameter will be passed on the stack. At the end of the canned >>code block, the code copies the return address from (SP+0) to >>(SP+4), then adds 4 to SP, then returns. This would be right if >>there was a 32-bit parameter on the stack, but this parameter is >>now passed in registers. As a result, some data further up the >>stack is clobbered, and the MCU may or may not return to >>somewhere meaningful, depending on the stack usage of the >>function that invokes div32u/mod32u. I'm not sure whether >>the canned code for div32u/mod32u comes from a library, or is >>hard-coded into the compiler, but in either case, I think it needs >>to be updated to be compatible with this new calling convention. >> >>Regards >> >>Kris >>-- >>Kris Heidenstrom Embedded systems designer / programmer >>kris@abbey.co.nz Abbey Systems Ltd - Telemetry Specialists >>Wellington NEW ZEALAND Voice +64-4-385-6611 Fax +64-4-385-6848 >> >> >>_______________________________________________ >>Icc-430 mailing list >>Icc-430@imagecraft.com >>http://dragonsgate.net/mailman/listinfo/icc-430 > > // richard (This email is for mailing lists. To reach me directly, please > use richard at imagecraft.com) > > _______________________________________________ > Icc-430 mailing list > Icc-430@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-430 > From richard-lists at imagecraft.com Wed Jan 24 00:55:35 2007 From: richard-lists at imagecraft.com (Richard) Date: Wed Jan 24 01:02:53 2007 Subject: [Icc-430] Interrupt handler wrapper preserves R8,9 - repost In-Reply-To: <00da01c73f2c$de4c4600$1917a8c0@KH> References: <00da01c73f2c$de4c4600$1917a8c0@KH> Message-ID: <6.1.0.6.2.20070124005342.053cb250@192.168.100.42> Kris, there is no interrupt wrapper per se. The compiler checks what the register usage is for an interrupt function and only save and restore what are used. If you have a test case that shows otherwise, then it is a bug. So contact me offlist with the source code and I will take a look at it. If an ISR calls another function, then the compiler will save/restore all registers as it wouldn't know what get used in the end, but this doesn't sound like your issue. At 12:27 PM 1/23/2007, Kris Heidenstrom wrote: >I think the descriptions in the help are right and >up-to-date, and I think the interrupt handler >wrapper is out-of-date. I wrote my own wrapper >in assembler, which does not preserve R8 and >R9, and everything seemed to work OK. >Am I missing something here? > >Kris >- // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From kris at abbey.co.nz Thu Jan 25 12:10:24 2007 From: kris at abbey.co.nz (Kris Heidenstrom) Date: Thu Jan 25 12:17:43 2007 Subject: [Icc-430] Re: Interrupt handler wrapper preserves R8,9 - repost References: <00da01c73f2c$de4c4600$1917a8c0@KH> <6.1.0.6.2.20070124005342.053cb250@192.168.100.42> Message-ID: <004d01c740bc$d98acc90$1917a8c0@KH> Richard wrote: > Kris, there is no interrupt wrapper per se. The compiler checks > what the register usage is for an interrupt function and only save > and restore what are used. If you have a test case that shows > otherwise, then it is a bug. So contact me offlist with the source > code and I will take a look at it. > > If an ISR calls another function, then the compiler will save/ > restore all registers as it wouldn't know what get used in the > end, but this doesn't sound like your issue. Sorry, I was not clear. I should have said... my interrupt handler calls a function. That's all it does. (The function is also called from elsewhere.) So the interrupt handler code itself doesn't destroy any registers, it is only the called function that does. That's why I listed the descriptions of the "preserved registers" and "volatile registers" from the help. The wrapper doesn't need to preserve the preserved registers, because the called function will preserve any of them that it uses. In fact the wrapper doesn't preserve R4~7 for this reason, but it _does_ preserve R8,9, which are "preserved registers" just like R4~7. In my case the called function doesn't use R8,9 at all, but if it did, it would preserve them (according to the help), because they are "preserved registers", so the wrapper doesn't need to preserve them, it just needs to preserve the "volatile registers", R10~15, as also stated in the help: "If you write a handler in assembly and if it calls normal C functions, then the assembly handler must save and restore the volatile registers, since normal C functions do not preserve them". My guess is that when the compiler sees that the interrupt handler is calling a function, it flags a list of registers as "needing to be preserved by the wrapper", and this list wrongly includes R8,9 as well as (rightly) R10~15. Kris -- Kris Heidenstrom Embedded systems designer / programmer kris@abbey.co.nz Abbey Systems Ltd - Telemetry Specialists Wellington NEW ZEALAND Voice +64-4-385-6611 Fax +64-4-385-6848 From kris at abbey.co.nz Thu Jan 25 12:35:41 2007 From: kris at abbey.co.nz (Kris Heidenstrom) Date: Thu Jan 25 12:43:01 2007 Subject: [Icc-430] Re: V7.05 BETA0 - error in handling of longs indiv32u/mod32u? References: <6.1.0.6.2.20070121163248.0893d7b0@192.168.100.42> <002a01c73f72$26516a80$1917a8c0@KH> <6.1.0.6.2.20070123214907.08b60868@192.168.100.42> <1565.69.59.200.77.1169620730.squirrel@webmail.peak.org> Message-ID: <006001c740c0$619d5d70$1917a8c0@KH> Kirk Bailey wrote: > Any chance you have a mix of modules/libraries > built with different compiler versions (and calling > conventions)? I had a weird case of this myself > not too long ago... Yes, that's exactly what has happened. I was using a project that I had created under version 6 of the compiler. Since the paths to the include files and libraries are explicitly specified in the project, they have to be manually updated from "\icc\include" and "\icc\lib" to "\iccv7430\include" and "\iccv7430\lib" when the project is moved from version 6 to version 7 of the compiler. I guess it's not really ideal for project files to become incompatible in this way, and the problem would be avoided if the compiler warned about the out-of-date library version/date or path, but it's not hard to work around manually. A warning about this would have been appropriate in the readme file though, but since it's nearly a year since version 7 was released, there's not much point adding it now... I hadn't had any problems until version 7.05b0. I guess the libraries and include files were compatible enough between version 6 and version 7 that using the old ones didn't cause a problem. Thanks Kirk for your help. BTW I see the code for div32u is now much better-arranged, thanks for that too! Kris -- Kris Heidenstrom Embedded systems designer / programmer kris@abbey.co.nz Abbey Systems Ltd - Telemetry Specialists Wellington NEW ZEALAND Voice +64-4-385-6611 Fax +64-4-385-6848 From richard-lists at imagecraft.com Thu Jan 25 13:06:12 2007 From: richard-lists at imagecraft.com (Richard) Date: Thu Jan 25 13:13:39 2007 Subject: [Icc-430] Re: Interrupt handler wrapper preserves R8,9 - repost In-Reply-To: <004d01c740bc$d98acc90$1917a8c0@KH> References: <00da01c73f2c$de4c4600$1917a8c0@KH> <6.1.0.6.2.20070124005342.053cb250@192.168.100.42> <004d01c740bc$d98acc90$1917a8c0@KH> Message-ID: <6.1.0.6.2.20070125125945.08750118@192.168.100.42> The problem here is that the compiler does not compute the total register usage of all functions nor generate a call graph (it can't anyway) so if your ISR calls out to another routine, that routine can be anything! C, asm, who knows that may eventually touch preserved registers etc. In theory, we can ignore the preserved registers IF the users read the manual and obey the calling convention. However, if they don't, their ISR may fail randomly and usually the compiler gets blamed for random failures :-) [ Just have a case where a user says: hey the AVR compiler is unreliable when my program gets bigger than 64K bytes on the AVR, and it turns out to be his hardware power supply problem... The worst is people are very keen on blaming the compiler and usually not tell me when they found out it's not the compiler problem after all, leaving me wondering whether it is a compiler .... but I digress. sorry] Anyway, I know what you are saying, I am just weighting the PROs and CONs... At 12:10 PM 1/25/2007, Kris Heidenstrom wrote: ...Sorry, I was not clear. I should have said... my interrupt handler >calls a function. That's all it does. (The function is also called from >elsewhere.) So the interrupt handler code itself doesn't destroy >any registers, it is only the called function that does. That's why I >listed the descriptions of the "preserved registers" and "volatile >registers" from the help. > >... // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From richard-lists at imagecraft.com Thu Jan 25 13:12:49 2007 From: richard-lists at imagecraft.com (Richard) Date: Thu Jan 25 13:20:15 2007 Subject: [Icc-430] Re: V7.05 BETA0 - error in handling of longs indiv32u/mod32u? In-Reply-To: <006001c740c0$619d5d70$1917a8c0@KH> References: <6.1.0.6.2.20070121163248.0893d7b0@192.168.100.42> <002a01c73f72$26516a80$1917a8c0@KH> <6.1.0.6.2.20070123214907.08b60868@192.168.100.42> <1565.69.59.200.77.1169620730.squirrel@webmail.peak.org> <006001c740c0$619d5d70$1917a8c0@KH> Message-ID: <6.1.0.6.2.20070125130832.05be3728@192.168.100.42> Hmm... I thought I changed to names of the internal functions so when you have incompatible lib versions, the linker will barf, but may be I forgot at the last minute. Sorry about that. I will make the name changes in the final release so this will be apparent. Unfortunately, there is no versioning info, and the worst on top is that V6 projects pretty much require you to have the include and lib paths as part of your project. At 12:35 PM 1/25/2007, Kris Heidenstrom wrote: ... >I guess it's not really ideal for project files to become >incompatible in this way, and the problem would be >avoided if the compiler warned about the out-of-date >library version/date or path, but it's not hard to work >around manually. A warning about this would have >been appropriate in the readme file though, but since >it's nearly a year since version 7 was released, there's >not much point adding it now... > // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From bailey at peak.org Thu Jan 25 15:11:44 2007 From: bailey at peak.org (bailey@peak.org) Date: Thu Jan 25 15:18:54 2007 Subject: [Icc-430] Re: Interrupt handler wrapper preserves R8,9 - repost In-Reply-To: <6.1.0.6.2.20070125125945.08750118@192.168.100.42> References: <00da01c73f2c$de4c4600$1917a8c0@KH> <6.1.0.6.2.20070124005342.053cb250@192.168.100.42> <004d01c740bc$d98acc90$1917a8c0@KH> <6.1.0.6.2.20070125125945.08750118@192.168.100.42> Message-ID: <1103.69.59.200.77.1169766704.squirrel@webmail.peak.org> Richard, As I commented earlier, I strongly agree with Kris on this. I understand your point of view well (I spent a decade doing compiler support myself!), but if you follow your logic further you would decide that you really should preserve ALL the registers with the wrapper, "just in case"! This is a real issue for folks and you already have a calling convention that you have defined and is well documented. Better that folks that follow the rules get good results than people who don't follow the rules have bad code with a slightly higher chance of working by accident. My two cents. Kirk Bailey bailey@peak.org > The problem here is that the compiler does not compute the total register > usage of all functions nor generate a call graph (it can't anyway) so if > your ISR calls out to another routine, that routine can be anything! C, > asm, who knows that may eventually touch preserved registers etc. In > theory, we can ignore the preserved registers IF the users read the manual > and obey the calling convention. However, if they don't, their ISR may > fail > randomly and usually the compiler gets blamed for random failures :-) [ > Just have a case where a user says: hey the AVR compiler is unreliable > when > my program gets bigger than 64K bytes on the AVR, and it turns out to be > his hardware power supply problem... The worst is people are very keen on > blaming the compiler and usually not tell me when they found out it's not > the compiler problem after all, leaving me wondering whether it is a > compiler .... but I digress. sorry] > > Anyway, I know what you are saying, I am just weighting the PROs and > CONs... > > At 12:10 PM 1/25/2007, Kris Heidenstrom wrote: > ...Sorry, I was not clear. I should have said... my interrupt handler >>calls a function. That's all it does. (The function is also called from >>elsewhere.) So the interrupt handler code itself doesn't destroy >>any registers, it is only the called function that does. That's why I >>listed the descriptions of the "preserved registers" and "volatile >>registers" from the help. >> >>... > > // richard (This email is for mailing lists. To reach me directly, please > use richard at imagecraft.com) > > _______________________________________________ > Icc-430 mailing list > Icc-430@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-430 > From richard-lists at imagecraft.com Thu Jan 25 16:05:58 2007 From: richard-lists at imagecraft.com (Richard) Date: Thu Jan 25 16:13:22 2007 Subject: [Icc-430] Re: Interrupt handler wrapper preserves R8,9 - repost In-Reply-To: <1103.69.59.200.77.1169766704.squirrel@webmail.peak.org> References: <00da01c73f2c$de4c4600$1917a8c0@KH> <6.1.0.6.2.20070124005342.053cb250@192.168.100.42> <004d01c740bc$d98acc90$1917a8c0@KH> <6.1.0.6.2.20070125125945.08750118@192.168.100.42> <1103.69.59.200.77.1169766704.squirrel@webmail.peak.org> Message-ID: <6.1.0.6.2.20070125160452.088ee978@192.168.100.42> OK, for the final release, I will change the compiler not to save/restore the preserved registers even if there is an external function call. At 03:11 PM 1/25/2007, bailey@peak.org wrote: >Richard, > As I commented earlier, I strongly agree with Kris on this. I >understand your point of view well (I spent a decade doing compiler support >myself!), but if you follow your logic further you would decide that you >really should preserve ALL the registers with the wrapper, "just in case"! > > This is a real issue for folks and you already have a calling convention >that you have defined and is well documented. Better that folks that follow >the rules get good results than people who don't follow the rules have >bad code with a slightly higher chance of working by accident. > // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From kris at abbey.co.nz Thu Jan 25 18:22:29 2007 From: kris at abbey.co.nz (Kris Heidenstrom) Date: Thu Jan 25 18:29:42 2007 Subject: [Icc-430] Re: Interrupt handler wrapper preserves R8,9 - repost References: <00da01c73f2c$de4c4600$1917a8c0@KH> <6.1.0.6.2.20070124005342.053cb250@192.168.100.42> <004d01c740bc$d98acc90$1917a8c0@KH> <6.1.0.6.2.20070125125945.08750118@192.168.100.42> <1103.69.59.200.77.1169766704.squirrel@webmail.peak.org> Message-ID: <00a601c740f0$d468dfc0$1917a8c0@KH> Kirk Bailey wrote: > As I commented earlier, I strongly agree with Kris on this. > I understand your point of view well (I spent a decade > doing compiler support myself!), but if you follow your > logic further you would decide that you really should > preserve ALL the registers with the wrapper, "just in > case"! Exactly... If you really think that the called code could destroy _everything_, the compiler should preserve R4~7 as well. There's nothing special about R8 and R9 that makes them more likely to be clobbered by code that doesn't comply with your conventions. I think you have to assume that it will follow the standard register allocation and calling conventions as stated in the help. > This is a real issue for folks and you already have a > calling convention that you have defined and is well > documented. Better that folks that follow the rules > get good results than people who don't follow the > rules have bad code with a slightly higher chance of > working by accident. Well put :-) -- Kris Heidenstrom Embedded systems designer / programmer kris@abbey.co.nz Abbey Systems Ltd - Telemetry Specialists Wellington NEW ZEALAND Voice +64-4-385-6611 Fax +64-4-385-6848