The patch fixed the internal error will be released next week. Please send the file to support@supp... Best Regards, Processor Expert Support --- In 68HC12@68HC..., "Relson, David" <relson@a...> wrote: > > Yesterday I upgraded from 2.92 to 2.95.01. There's no difference in > behavior. > > I have a 140k zip file that contains a complete CW/PE project and > demonstrates the problem I'm having. That seems a bit large to send to > the list. I can post it or send it to you via email (if you'd care to > contact me off-list). > > Regards, > > David > > By the way one side effect of that is when PE generates code I get the > following error: > > Metrowerks HC12 C Compiler > INTERNAL ERROR: at line 566: Unknown macro: "n" (file: > Config\Compiler\MetrowerksHC12CC.chg) > Hint: The -BfaGapLimitBits4294967295 compiler options has been > added to the current target. > > -----Original Message----- > From: 68HC12@68HC... [mailto:68HC12@68HC...] On Behalf > Of processor_expert > Sent: Tuesday, December 06, 2005 9:23 AM > To: 68HC12@68HC... > Subject: [68HC12] Re: processor expert & writing flash memory > > Hi, > > What version of Processor Expert do you use? Do you have the latest > version? Is it possible to send us any project with CPU bean setting > to analyze your problem? > > Best Regards, > Processor Expert Support > > --- In 68HC12@68HC..., David Relson <relson@o...> wrote: > > > > Greetings, > > > > I'm using Metrowerks CodeWarrior 3.1 with Processor Expert to > develop an > > embedded boot loader for an MC9S12A64 (64k flash). It needs to > write > > to multiple pages, for example addresses 3C8000 ff and 3D8000 ff. > > After writing to 3C8000, the 3D8000 write is failing because bank > > changing isn't happening. > > > > As best I can tell, in datapage.c symbol USE_SEVERAL_PAGES is 0 so > the > > code isn't setting the page register. > > > > I'm new to CodeWarrior and Processor Expert and it's not at all > clear > > what to change to fix this problem. > > > > Looking forward to a helpful answer, I remain > > > > Cordially yours, > > > > David > > Yahoo! Groups Links >

Hi Daniel, You found the solution. Adding HCS12 as a preprocessor symbol makes datapage do the right thing! Thank you very much for pointing me in that direction. In retrospect it should have been obvious, but I missed it. Regards, David -----Original Message----- From: 68HC12@68HC... [mailto:68HC12@68HC...] On Behalf Of Daniel Friederich Sent: Tuesday, December 06, 2005 3:09 PM To: 68HC12@68HC... Subject: Re: [Fwd: Re: processor expert & writing flash memoryre: Re: [68HC12] Digest Number 1301] For the HCS12 A 64, PPAGE is at 0x30, not at 0x35. So the page store should be "5b30 STAB 0x30" And inside of datapage.c: #if defined(HCS12) || defined(_HCS12) /* HCS12 family has PPAGE register only at 0x30 */ #define PPAGE_ADDR (0x30+REGISTER_BASE) #ifndef __PPAGE__ /* may be set already by option -CPPPAGE */ #define __PPAGE__ #endif So try to use the option -D_HCS12 Daniel

Hi Robert, Like you, all my code is C. When I realized that the FLASH bean wasn't writing what/where I wanted, I started looking more closely at what's happening. With MC6809 experience from years past, stepping through 6812 code isn't too hard. That process lead me into the depths of FLASH.C and DATAPAGE.C - the files from which I excerpted relevant bits of code. My comment about "setting 1 register" was based on the idea that microcontroller behavior is controlled (enabled/disabled) by its registers and the thought that something special needs to be enabled in order for paged memory access (a.k.a. "banking") to work. My understanding of the PRM file matches yours. It provides information needed by the linker so that code and data can be properly placed in memory. Regards, David

For the HCS12 A 64, PPAGE is at 0x30, not at 0x35. So the page store should be "5b30 STAB 0x30" And inside of datapage.c: #if defined(HCS12) || defined(_HCS12) /* HCS12 family has PPAGE register only at 0x30 */ #define PPAGE_ADDR (0x30+REGISTER_BASE) #ifndef __PPAGE__ /* may be set already by option -CPPPAGE */ #define __PPAGE__ #endif So try to use the option -D_HCS12 Daniel Robert Lewis wrote: >David, > >This bounced on your email; rejected by the server so I will post it >here. Since I write only in C this may not be entirely relavent to what >you are looking for. > >"/* >AFAICT, the crux of the matter is the following bits from Flash.c > > 88: ** =================================================================== > 89: ** Method : WriteWord (bean IntFLASH) > 90: ** > 91: ** Description : > 92: ** This method is internal. It is used by Processor Expert > 93: ** only. > 94: ** =================================================================== > 95: */ > 96: static byte WriteWord(dword Addr,word Data16) > > ...[snip]... > 106: *(word *far) Addr = Data16; /* Array address and program data */ > 001d ed88 LDY 8,SP > 001f e687 LDAB 7,SP > 0021 ee80 LDX 0,SP > 0023 160000 JSR _STORE_FAR_16 > >and what happens within _STORE_FAR_16 (where lines 628 to 632 don't change the page): > > 606: #if USE_SEVERAL_PAGES > ...[snipped disabled code]... > 626: #else /* USE_SEVERAL_PAGES */ > 627: asm { > 628: PSHA ; save A register > 0000 36 PSHA > 629: LDAA PAGE_ADDR ; save page register > 0001 9635 LDAA 53 > 630: STAB PAGE_ADDR ; set page register > 0003 5b35 STAB 53 > 631: STX 0,Y ; store the value passed in X > 0005 6e40 STX 0,Y > 632: STAA PAGE_ADDR ; restore page register > 0007 5a35 STAA 53 > 633: PULA ; restore A register > 0009 32 PULA > 634: RTS > 000a 3d RTS > 635: } > 636: #endif /* USE_SEVERAL_PAGES */ > 637: } >*/ > >It seems that setting the page register (line 630) has no effect. I've stepped through the code and see that X has the proper data value while A and Y have proper address values. Why it's failing to work has me baffled. > >" >======================================================================================================= >What I would suggest is that you write a C routine to store a number >near and then far, also do a call near and far TestFcnNear(), and >TestFcnFar() and disassemble the code in the CW assembler window. Then >step through and check how the memory mapping is set. > >As far as I know the prm file is only used during the compile to set the >call instructions for the memory map which are functions built during >the generation of datapage.c (I write in C so maybe this is different >for assembler); start12 sets the module routing register for the flash >and spi etc. Once the machine architecture via the routing register is >set, it never gets changed unless you write the code to change it. I >think the memory mapping registers are changed inline in the code using >the code generated in datapage.c for the different types of SR calls. >As you can see in the snip following, it appears that more then just the >memory map register must be set. There are offset registers as well. > >So I don't think you can just set one register and expect all the code >to execute 'as is' unless you have written relocatable code. > >But perhaps there are others that could improve on my understanding. The >following is from datapage.c > >" Runtime routine to set the right page register. This routine is used >if the compiler > does not know the right page register, i.e. if the option -Cp is used >for more than > one pageregister or if the runtime option is used for one of the -Cp >options. > > Arguments : > - offset part of an address in the Y register > - page part of an address in the B register > > Result : > - page part written into the correct page register. > - the old page register content is destroyed > - all processor registers remains unchanged >" > >Regards > >Robert Lewis > > >Yahoo! Groups Links

David, This bounced on your email; rejected by the server so I will post it here. Since I write only in C this may not be entirely relavent to what you are looking for. "/* AFAICT, the crux of the matter is the following bits from Flash.c 88: ** =================================================================== 89: ** Method : WriteWord (bean IntFLASH) 90: ** 91: ** Description : 92: ** This method is internal. It is used by Processor Expert 93: ** only. 94: ** =================================================================== 95: */ 96: static byte WriteWord(dword Addr,word Data16) ...[snip]... 106: *(word *far) Addr = Data16; /* Array address and program data */ 001d ed88 LDY 8,SP 001f e687 LDAB 7,SP 0021 ee80 LDX 0,SP 0023 160000 JSR _STORE_FAR_16 and what happens within _STORE_FAR_16 (where lines 628 to 632 don't change the page): 606: #if USE_SEVERAL_PAGES ...[snipped disabled code]... 626: #else /* USE_SEVERAL_PAGES */ 627: asm { 628: PSHA ; save A register 0000 36 PSHA 629: LDAA PAGE_ADDR ; save page register 0001 9635 LDAA 53 630: STAB PAGE_ADDR ; set page register 0003 5b35 STAB 53 631: STX 0,Y ; store the value passed in X 0005 6e40 STX 0,Y 632: STAA PAGE_ADDR ; restore page register 0007 5a35 STAA 53 633: PULA ; restore A register 0009 32 PULA 634: RTS 000a 3d RTS 635: } 636: #endif /* USE_SEVERAL_PAGES */ 637: } */ It seems that setting the page register (line 630) has no effect. I've stepped through the code and see that X has the proper data value while A and Y have proper address values. Why it's failing to work has me baffled. " ======================================================================================================= What I would suggest is that you write a C routine to store a number near and then far, also do a call near and far TestFcnNear(), and TestFcnFar() and disassemble the code in the CW assembler window. Then step through and check how the memory mapping is set. As far as I know the prm file is only used during the compile to set the call instructions for the memory map which are functions built during the generation of datapage.c (I write in C so maybe this is different for assembler); start12 sets the module routing register for the flash and spi etc. Once the machine architecture via the routing register is set, it never gets changed unless you write the code to change it. I think the memory mapping registers are changed inline in the code using the code generated in datapage.c for the different types of SR calls. As you can see in the snip following, it appears that more then just the memory map register must be set. There are offset registers as well. So I don't think you can just set one register and expect all the code to execute 'as is' unless you have written relocatable code. But perhaps there are others that could improve on my understanding. The following is from datapage.c " Runtime routine to set the right page register. This routine is used if the compiler does not know the right page register, i.e. if the option -Cp is used for more than one pageregister or if the runtime option is used for one of the -Cp options. Arguments : - offset part of an address in the Y register - page part of an address in the B register Result : - page part written into the correct page register. - the old page register content is destroyed - all processor registers remains unchanged " Regards Robert Lewis

Yesterday I upgraded from 2.92 to 2.95.01. There's no difference in behavior. I have a 140k zip file that contains a complete CW/PE project and demonstrates the problem I'm having. That seems a bit large to send to the list. I can post it or send it to you via email (if you'd care to contact me off-list). Regards, David By the way one side effect of that is when PE generates code I get the following error: Metrowerks HC12 C Compiler INTERNAL ERROR: at line 566: Unknown macro: "n" (file: Config\Compiler\MetrowerksHC12CC.chg) Hint: The -BfaGapLimitBits4294967295 compiler options has been added to the current target. -----Original Message----- From: 68HC12@68HC... [mailto:68HC12@68HC...] On Behalf Of processor_expert Sent: Tuesday, December 06, 2005 9:23 AM To: 68HC12@68HC... Subject: [68HC12] Re: processor expert & writing flash memory Hi, What version of Processor Expert do you use? Do you have the latest version? Is it possible to send us any project with CPU bean setting to analyze your problem? Best Regards, Processor Expert Support --- In 68HC12@68HC..., David Relson <relson@o...> wrote: > > Greetings, > > I'm using Metrowerks CodeWarrior 3.1 with Processor Expert to develop an > embedded boot loader for an MC9S12A64 (64k flash). It needs to write > to multiple pages, for example addresses 3C8000 ff and 3D8000 ff. > After writing to 3C8000, the 3D8000 write is failing because bank > changing isn't happening. > > As best I can tell, in datapage.c symbol USE_SEVERAL_PAGES is 0 so the > code isn't setting the page register. > > I'm new to CodeWarrior and Processor Expert and it's not at all clear > what to change to fix this problem. > > Looking forward to a helpful answer, I remain > > Cordially yours, > > David > Yahoo! Groups Links

Hi, What version of Processor Expert do you use? Do you have the latest version? Is it possible to send us any project with CPU bean setting to analyze your problem? Best Regards, Processor Expert Support --- In 68HC12@68HC..., David Relson <relson@o...> wrote: > > Greetings, > > I'm using Metrowerks CodeWarrior 3.1 with Processor Expert to develop an > embedded boot loader for an MC9S12A64 (64k flash). It needs to write > to multiple pages, for example addresses 3C8000 ff and 3D8000 ff. > After writing to 3C8000, the 3D8000 write is failing because bank > changing isn't happening. > > As best I can tell, in datapage.c symbol USE_SEVERAL_PAGES is 0 so the > code isn't setting the page register. > > I'm new to CodeWarrior and Processor Expert and it's not at all clear > what to change to fix this problem. > > Looking forward to a helpful answer, I remain > > Cordially yours, > > David >

David, I found something similiar with trying to get the flash to work on a 9s12dg128 using PE beans and CW. What I eventually learned was that the prm file had to be manually edited, or the mapping registers were wrong. Then once having set that up you have to change the options in CW to notify you of any changed files; if you don't PE will overwrite your prm file if the code is regenerated and you will be using the default mapping which may not be what you intend. There may be other ways to do this but this is the way I found; setting ust the options in the PE bean for the cpu didn't do the trick. You have to manually edit the prm file, or so Freescale Tech support said. Here is my prm file which the EEPROM_DATA added to go into RAM for debugging, and then the last one into Flash. I cut out the bean header to save email space. Becareful of the stack size in PE, it defaults to some foolishly low number and can cause you grief if you do not change it up. PE has great concepts but there are a lot of pitfalls. Regards Robert Lewis //========================================= this is for RAM ============================== NAMES END SECTIONS /* List of all sections specified on the "Build options" tab */ RAM_2000 = READ_WRITE 0x00002000 TO 0x00003FFF; ROM_C000 = READ_ONLY 0x0000C000 TO 0x0000FEFF; ROM_4000 = READ_ONLY 0x00004000 TO 0x00007FFF; ROM_FF10 = READ_ONLY 0x0000FF10 TO 0x0000FF7F; ROM_PAGE3D = READ_ONLY 0x003D8000 TO 0x003DBFFF; ROM_PAGE3C = READ_ONLY 0x003C8000 TO 0x003CBFFF; ROM_PAGE3B = READ_ONLY 0x003B8000 TO 0x003BBFFF; ROM_PAGE3A = READ_ONLY 0x003A8000 TO 0x003ABFFF; ROM_PAGE39 = READ_ONLY 0x00398000 TO 0x0039BFFF; ROM_PAGE38 = READ_ONLY 0x00388000 TO 0x0038BFFF; EEPROM_0800 = NO_INIT 0x00000800 TO 0x00000FEF; END PLACEMENT DEFAULT_RAM INTO RAM_2000; EEPROM_DATA INTO RAM_2000; DEFAULT_ROM INTO ROM_PAGE3D, ROM_PAGE3C, ROM_PAGE3B, ROM_PAGE3A, ROM_PAGE39, ROM_PAGE38; _PRESTART, STARTUP, ROM_VAR, STRINGS, NON_BANKED, COPY INTO ROM_C000, ROM_4000, ROM_FF10; END INIT _EntryPoint /* The entry point of the application. This function is generated into the CPU module. */ STACKSIZE 0x0200 /* Size of the system stack. Value can be changed on the "Build options" tab */ //========================================= this is for flash============================== NAMES END SECTIONS /* List of all sections specified on the "Build options" tab */ RAM_2000 = READ_WRITE 0x00002000 TO 0x00003FFF; ROM_C000 = READ_ONLY 0x0000C000 TO 0x0000FEFF; ROM_4000 = READ_ONLY 0x00004000 TO 0x00007FFF; ROM_FF10 = READ_ONLY 0x0000FF10 TO 0x0000FF7F; ROM_PAGE3D = READ_ONLY 0x003D8000 TO 0x003DBFFF; ROM_PAGE3C = READ_ONLY 0x003C8000 TO 0x003CBFFF; ROM_PAGE3B = READ_ONLY 0x003B8000 TO 0x003BBFFF; ROM_PAGE3A = READ_ONLY 0x003A8000 TO 0x003ABFFF; ROM_PAGE39 = READ_ONLY 0x00398000 TO 0x0039BFFF; ROM_PAGE38 = READ_ONLY 0x00388000 TO 0x0038BFFF; EEPROM_0800 = NO_INIT 0x00000800 TO 0x00000FEF ALIGN [>=4:4]; END PLACEMENT DEFAULT_RAM INTO RAM_2000; EEPROM_DATA INTO EEPROM_0800; DEFAULT_ROM INTO ROM_PAGE3D, ROM_PAGE3C, ROM_PAGE3B, ROM_PAGE3A, ROM_PAGE39, ROM_PAGE38; _PRESTART, STARTUP, ROM_VAR, STRINGS, NON_BANKED, COPY INTO ROM_C000, ROM_4000, ROM_FF10; END INIT _EntryPoint /* The entry point of the application. This function is generated into the CPU module. */ STACKSIZE 0x0200 /* Size of the system stack. Value can be changed on the "Build options" tab */ Message: 7 Date: Sun, 4 Dec 2005 23:19:31 -0500 From: David Relson <relson@rels...> Subject: processor expert & writing flash memory Greetings, I'm using Metrowerks CodeWarrior 3.1 with Processor Expert to develop an embedded boot loader for an MC9S12A64 (64k flash). It needs to write to multiple pages, for example addresses 3C8000 ff and 3D8000 ff. After writing to 3C8000, the 3D8000 write is failing because bank changing isn't happening. As best I can tell, in datapage.c symbol USE_SEVERAL_PAGES is 0 so the code isn't setting the page register. I'm new to CodeWarrior and Processor Expert and it's not at all clear what to change to fix this problem. Looking forward to a helpful answer, I remain Cordially yours, David