From: SourceForge.net <no...@so...> - 2003-11-28 13:52:05
|
Bugs item #850747, was opened at 2003-11-28 05:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=850747&group_id=599 Category: msc51(8051) target Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: no cypress compatability Initial Comment: The variable initialisation code which is delivered with your sdcc enviroment is not compatible to the cypress fx2 chip. I recognized the problem because I have extern xdata ram at 0x8000 and some memory mapped io in the range from 0x0000 to 0x7FFF. The variables which I located in this extern s-ram memory at 0x8000 weren't initialized at startup. So I analized your code in the generated assembler file containing the main function at the "__sdcc_init_data:" label, where the values should be copied to the right xdata location. There I found that this code is not fx2 compatible. your initialisation code: __sdcc_init_data: ; _mcs51_genXINIT() start mov a,#l_XINIT orl a,#l_XINIT>>8 jz 00003$ mov a,#s_XINIT add a,#l_XINIT mov r1,a mov a,#s_XINIT>>8 addc a,#l_XINIT>>8 mov r2,a mov dptr,#s_XINIT mov r0,#s_XISEG /* !!! here ist the probem: The address bus of the cypress fx2 is not multiplexed like the original mcs51. It has 16 pins for the address bus and 8 pins for the data bus. So p2 represents not A[8..15] at the fx2! */ mov p2,#(s_XISEG >> 8) 00001$: clr a movc a,@a+dptr movx @r0,a inc dptr inc r0 cjne r0,#0,00002$ inc p2 00002$: mov a,dpl cjne a,ar1,00001$ mov a,dph cjne a,ar2,00001$ mov p2,#0xFF 00003$: ; _mcs51_genXINIT() end If this code is used on a fx2 the high byte of the xdata address will take no effect and the values will be written anywhere in the xdata from 0x0000 and 0x00FF. So you must also use dptr to write on the xtram. With a few changes the code does its work also on the cypress chip: //_mcs51_genXINIT() start /* if l_XINIT==0 jump to end */ mov a,#l_XINIT orl a,#l_XINIT>>8 jz endof_xinit; /* calculate end address of XINIT segment : [r2..r3] = s_XINIT + l_XINIT high byte: r3; low byte: r2 */The variable initialisation code which is delivered mov a,#s_XINIT add a,#l_XINIT mov r2,a mov a,#s_XINIT>>8 addc a,#l_XINIT>>8 mov r3,a /* load datapointer with XINIT start address */ mov dptr,#s_XINIT /* store start address of s_XISEG t0 r0 and r1 */The variable initialisation code which is delivered mov r0,#s_XISEG mov r1,#(s_XISEG >> 8) loop_1: clr a /* copy byte to acc */ movc a,@a+dptr inc dptr push dpl push dph /* copy acc to XRAM destination */ mov dpl,r0 mov dph,r1 movx @dptr,a inc dptr mov r0,dpl mov r1,dphThe variable initialisation code which is delivered pop dph pop dpl /* look if end of segment is reached */ mov a,dpl cjne a,ar2,loop_1 mov a,dph cjne a,ar3,loop_1 endof_xinit: I hope you will take care on this point in your future releases. I hope also that the compiler generates in no case xdata access with "movx a,@r0" and p2 combinations. compiler options: --model-large --xram-loc 0x8000 compiler version: 2.3.5 (Sep 1 2003) (UNIX) I thank you very much for this wunderful compiler and wish you merry x-mas. Albert Zihlmann a.z...@fh... University of Applied Sciences Elektrotechnik und Informationstechnologie EIT CH-4132 Muttenz BL, Switzerland ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=850747&group_id=599 |
From: SourceForge.net <no...@so...> - 2003-11-28 18:45:47
|
Bugs item #850747, was opened at 2003-11-28 13:52 Message generated for change (Comment added) made by frief You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=850747&group_id=599 Category: msc51(8051) target Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: no cypress compatability Initial Comment: The variable initialisation code which is delivered with your sdcc enviroment is not compatible to the cypress fx2 chip. I recognized the problem because I have extern xdata ram at 0x8000 and some memory mapped io in the range from 0x0000 to 0x7FFF. The variables which I located in this extern s-ram memory at 0x8000 weren't initialized at startup. So I analized your code in the generated assembler file containing the main function at the "__sdcc_init_data:" label, where the values should be copied to the right xdata location. There I found that this code is not fx2 compatible. your initialisation code: __sdcc_init_data: ; _mcs51_genXINIT() start mov a,#l_XINIT orl a,#l_XINIT>>8 jz 00003$ mov a,#s_XINIT add a,#l_XINIT mov r1,a mov a,#s_XINIT>>8 addc a,#l_XINIT>>8 mov r2,a mov dptr,#s_XINIT mov r0,#s_XISEG /* !!! here ist the probem: The address bus of the cypress fx2 is not multiplexed like the original mcs51. It has 16 pins for the address bus and 8 pins for the data bus. So p2 represents not A[8..15] at the fx2! */ mov p2,#(s_XISEG >> 8) 00001$: clr a movc a,@a+dptr movx @r0,a inc dptr inc r0 cjne r0,#0,00002$ inc p2 00002$: mov a,dpl cjne a,ar1,00001$ mov a,dph cjne a,ar2,00001$ mov p2,#0xFF 00003$: ; _mcs51_genXINIT() end If this code is used on a fx2 the high byte of the xdata address will take no effect and the values will be written anywhere in the xdata from 0x0000 and 0x00FF. So you must also use dptr to write on the xtram. With a few changes the code does its work also on the cypress chip: //_mcs51_genXINIT() start /* if l_XINIT==0 jump to end */ mov a,#l_XINIT orl a,#l_XINIT>>8 jz endof_xinit; /* calculate end address of XINIT segment : [r2..r3] = s_XINIT + l_XINIT high byte: r3; low byte: r2 */The variable initialisation code which is delivered mov a,#s_XINIT add a,#l_XINIT mov r2,a mov a,#s_XINIT>>8 addc a,#l_XINIT>>8 mov r3,a /* load datapointer with XINIT start address */ mov dptr,#s_XINIT /* store start address of s_XISEG t0 r0 and r1 */The variable initialisation code which is delivered mov r0,#s_XISEG mov r1,#(s_XISEG >> 8) loop_1: clr a /* copy byte to acc */ movc a,@a+dptr inc dptr push dpl push dph /* copy acc to XRAM destination */ mov dpl,r0 mov dph,r1 movx @dptr,a inc dptr mov r0,dpl mov r1,dphThe variable initialisation code which is delivered pop dph pop dpl /* look if end of segment is reached */ mov a,dpl cjne a,ar2,loop_1 mov a,dph cjne a,ar3,loop_1 endof_xinit: I hope you will take care on this point in your future releases. I hope also that the compiler generates in no case xdata access with "movx a,@r0" and p2 combinations. compiler options: --model-large --xram-loc 0x8000 compiler version: 2.3.5 (Sep 1 2003) (UNIX) I thank you very much for this wunderful compiler and wish you merry x-mas. Albert Zihlmann a.z...@fh... University of Applied Sciences Elektrotechnik und Informationstechnologie EIT CH-4132 Muttenz BL, Switzerland ---------------------------------------------------------------------- >Comment By: Frieder Ferlemann (frief) Date: 2003-11-28 18:45 Message: Logged In: YES user_id=589052 Hi Albert, thanks for the report. This problem is also known as: [ 785979 ] xdata initialization fails on Cygnal parts http://sourceforge.net/tracker/ index.php?func=detail&aid=785979&group_id=599&atid=100599 where some proposals are made. There is a note in the manual about this in: Other Processors/MCS 51 variants To avoid fragmentation please lets continue this under #785979. Frieder ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=850747&group_id=599 |
From: SourceForge.net <no...@so...> - 2004-03-18 04:49:59
|
Bugs item #850747, was opened at 2003-11-28 07:52 Message generated for change (Comment added) made by epetrich You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=850747&group_id=599 Category: msc51(8051) target >Group: fixed >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Erik Petrich (epetrich) Summary: no cypress compatability Initial Comment: The variable initialisation code which is delivered with your sdcc enviroment is not compatible to the cypress fx2 chip. I recognized the problem because I have extern xdata ram at 0x8000 and some memory mapped io in the range from 0x0000 to 0x7FFF. The variables which I located in this extern s-ram memory at 0x8000 weren't initialized at startup. So I analized your code in the generated assembler file containing the main function at the "__sdcc_init_data:" label, where the values should be copied to the right xdata location. There I found that this code is not fx2 compatible. your initialisation code: __sdcc_init_data: ; _mcs51_genXINIT() start mov a,#l_XINIT orl a,#l_XINIT>>8 jz 00003$ mov a,#s_XINIT add a,#l_XINIT mov r1,a mov a,#s_XINIT>>8 addc a,#l_XINIT>>8 mov r2,a mov dptr,#s_XINIT mov r0,#s_XISEG /* !!! here ist the probem: The address bus of the cypress fx2 is not multiplexed like the original mcs51. It has 16 pins for the address bus and 8 pins for the data bus. So p2 represents not A[8..15] at the fx2! */ mov p2,#(s_XISEG >> 8) 00001$: clr a movc a,@a+dptr movx @r0,a inc dptr inc r0 cjne r0,#0,00002$ inc p2 00002$: mov a,dpl cjne a,ar1,00001$ mov a,dph cjne a,ar2,00001$ mov p2,#0xFF 00003$: ; _mcs51_genXINIT() end If this code is used on a fx2 the high byte of the xdata address will take no effect and the values will be written anywhere in the xdata from 0x0000 and 0x00FF. So you must also use dptr to write on the xtram. With a few changes the code does its work also on the cypress chip: //_mcs51_genXINIT() start /* if l_XINIT==0 jump to end */ mov a,#l_XINIT orl a,#l_XINIT>>8 jz endof_xinit; /* calculate end address of XINIT segment : [r2..r3] = s_XINIT + l_XINIT high byte: r3; low byte: r2 */The variable initialisation code which is delivered mov a,#s_XINIT add a,#l_XINIT mov r2,a mov a,#s_XINIT>>8 addc a,#l_XINIT>>8 mov r3,a /* load datapointer with XINIT start address */ mov dptr,#s_XINIT /* store start address of s_XISEG t0 r0 and r1 */The variable initialisation code which is delivered mov r0,#s_XISEG mov r1,#(s_XISEG >> 8) loop_1: clr a /* copy byte to acc */ movc a,@a+dptr inc dptr push dpl push dph /* copy acc to XRAM destination */ mov dpl,r0 mov dph,r1 movx @dptr,a inc dptr mov r0,dpl mov r1,dphThe variable initialisation code which is delivered pop dph pop dpl /* look if end of segment is reached */ mov a,dpl cjne a,ar2,loop_1 mov a,dph cjne a,ar3,loop_1 endof_xinit: I hope you will take care on this point in your future releases. I hope also that the compiler generates in no case xdata access with "movx a,@r0" and p2 combinations. compiler options: --model-large --xram-loc 0x8000 compiler version: 2.3.5 (Sep 1 2003) (UNIX) I thank you very much for this wunderful compiler and wish you merry x-mas. Albert Zihlmann a.z...@fh... University of Applied Sciences Elektrotechnik und Informationstechnologie EIT CH-4132 Muttenz BL, Switzerland ---------------------------------------------------------------------- >Comment By: Erik Petrich (epetrich) Date: 2004-03-17 22:49 Message: Logged In: YES user_id=635249 With the changes noted in ChangeLog 1.683, initialization can now be easily compatible with all of the Cypress EZ-USB family of parts (including FX2). For most cases, just define the sfr _PAGESFR at the location of the MPAGE register. For example, include the declaration: sfr at 0x92 _PAGESFR; /* MPAGE at 0x92 */ in any C file linked in a project. Most of the run-time startup/initialization is in a library now and thus can be overridden at the local level if more complex customizations are needed. ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2003-11-28 12:45 Message: Logged In: YES user_id=589052 Hi Albert, thanks for the report. This problem is also known as: [ 785979 ] xdata initialization fails on Cygnal parts http://sourceforge.net/tracker/ index.php?func=detail&aid=785979&group_id=599&atid=100599 where some proposals are made. There is a note in the manual about this in: Other Processors/MCS 51 variants To avoid fragmentation please lets continue this under #785979. Frieder ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=850747&group_id=599 |