Hello once more, I found the option and disabled it in SDCC 3.0.1 #6064. I also found some more problems in tinibios.c to get it working. So now the ds390 port assumes 16 bit mode by default and doesn't use flat24 before _sdcc_external_startup is called. Your _sdcc_external_startup should not call anything before setting ACON and it should fix the return address on the stack.
Maarten > Hi Arif, > > I modified src/ds390/main.c to surround the necessary > jumps and calls with .flat24 on/off statements and > looking at the generated code I would think this should > work. I don't think you need to separate it into several > files. Can you please verify if this works on a real > ds390? The code assumes that _sdcc_external_startup() > will change into flat24 mode as is done in tinibios.c. > > You will find the modification in the attached patch. I > cannot commit it to subversion yet, since it breaks the > regression tests. I'm pretty sure this is due to the > simulator being in flat24 mode upon startup. > > Maarten > > > Hello Maarten, > > > > (apologies in advance for a long message that follows here) > > > > > > You are right that SDCC puts ".flat24 on" at the top of the assembly code. > > Therefore all the addresses are in 24bit mode right from the first AJMP. > > This does NOT work (at least on our 80390 core based mcu) as the CPU is not > > in .flat24 bit mode at the reset. > > > > To confirm this, I coded some simple test code in assembly (to have a > > better control and to bypass SDCC C compiler). > > > > The test code had just two functions, each switching on a LED by writing to > > a register. > > The first function initializes LED 7 (_P3,#0x7F) while the other one > > initializes LED 5 (_P3,#0x5F). > > In all cases the original (hand coded not compiler generated) .asm file(s) > > is assembled/linked using the same commands. > > > > Case one: > > CPU16bit, Linker 16bit > > In this case CPU is not put in 24bit mode, neither ".flat24 > > on" directive is used for putting linker in 24 bit mode. > > Program works and both the LEDs (7&5) are switched on. > > > > Case two: > > CPU 24bit, Linker 16bit > > In this case CPU is put in 24bit mode (using _TA, _ACON > > sfrs) after the first function but ".flat24 on" directive is NOT used. > > So the linker does not know about it. > > The first half of the program works (as expected) i.e. > > first Led (7) is switched on but not the second one. > > > > Case three: > > CPU 24bit, Linker 24bit > > In this case CPU is put in 24bit mode after the first > > function AND ".flat24 on" directive is used (introduced in code after the > > first function). > > Program does not work at all (no Leds switched on). The > > problem is that ".flat24 on" affects the whole file (linker makes all > > addresses 24bit). > > > > Case four: > > CPU 24bit, Linker 24bit BUT IN SEPARATE FILES > > In this case CPU is put in 24bit mode after the first > > function AND ".flat24 on" directive is used but these operations are done > > in 2 separate files. > > Program works and both the LEDs (7&5) are switched on > > > > > > So the solution to this problem seems to be the last case where the startup > > code is split in the two separate files. The working code is as follows. > > > > > > > > File 1: > > > > 1 .module temp > > 2 > > 3 .area HOME (CODE) > > 4 > > 0000 5 __interrupt_vect: > > 0000 02 00 03 6 ljmp __sdcc_gsinit_startup > > > > > > > > > > File 2: > > > > 1 .module temp > > 2 > > 3 .area DSEG (DATA) > > 4 .area RSEG (ABS,DATA) > > 0000 5 .org 0x0000 > > 00B0 6 _P3 = 0x00b0 > > 009D 7 _ACON = 0x009d > > 00EB 8 _TA = 0x00eb > > 9 > > 10 .area REG_BANK_0 (REL,OVR,DATA) > > 0000 11 .ds 8 > > 12 > > 13 .area SSEG (DATA) > > 0008 14 __start__stack: > > 0008 15 .ds 1 > > 16 > > 17 .area HOME (CODE) > > 0003 18 __sdcc_gsinit_startup:: > > 0003 75 81 07 19 mov sp,#__start__stack - 1 > > 0006 53 B0 7F 20 anl _P3,#0x7F > > 0009 75 EB AA 21 mov _TA,#0xaa > > 000C 75 EB 55 22 mov _TA,#0x55 > > 000F 75 9D 02 23 mov _ACON,#0x02 ; Put the CPU > > in 24 bit mode > > 24 > > 25 .flat24 on ; 24 bit flat > > addressing > > 0012 02 00 00 16 26 ljmp __sdcc_program_startup > > 27 > > 0016 28 __sdcc_program_startup: > > 0016 53 B0 5F 29 anl _P3,#0x5F > > 0019 80 FE 30 sjmp . > > > > > > > > > > We can use the same mechanism for actual code generation from SDCC and if > > time will permit, I'll provide a patch later on. > > > > > > Thanks > > Arif > > > > > > -----Original Message----- > > From: Maarten Brock [mailto:[email protected]] > > Sent: Saturday, November 13, 2010 6:02 PM > > To: [email protected] > > Subject: Re: [Sdcc-user] SDCC DS390 Port and _sdcc_external_startup > > > > Hi Arif, > > > > I finally had some time to look at the ds390 code. It > > seems our simulator is in flat24 mode right from the > > start and thus the "AJMP __reset_vect" at 0x0000 works. > > I also looked in the ds390 user guide and it seems to > > have forgotten to mention AJMP addr19. This is all > > assuming the AJMP addr19 really doesn't work in 8051 > > mode and instead executes an AJMP addr11. > > > > I think the AJMP __reset_vect also needs to be generated > > with .flat24 off, but the interrupt vector should use > > .flat24 on again. How this will work with the ucsim > > simulator is another problem. > > > > I hope this helps and welcome your reply about success > > or failure. > > > > Maarten > > > > > Hello Maarten, > > > > > > I modified SDCC code generation so that ds390 flat24 mode if "off" before > > > calling _sdcc_external_startup function (which puts the CPU in 24bit > > > mode). > > > The extract from the new hello390.rst is as follows: > > > > > > ---- > > > 265 .flat24 off > > > 0043 266 __reset_vect: > > > 0043 02 00 4C 267 ljmp __sdcc_gsinit_startup > > > 268 > > > ;-------------------------------------------------------- > > > 269 ; global & static initialisations > > > 270 > > > ;-------------------------------------------------------- > > > 271 .area HOME (CODE) > > > 272 .area GSINIT (CODE) > > > 273 .area GSFINAL (CODE) > > > 274 .area GSINIT (CODE) > > > 004C 275 __sdcc_gsinit_startup: > > > 004C 75 81 22 276 mov sp,#__start__stack - 1 > > > 004F 12 00 B4 277 lcall __sdcc_external_startup > > > 278 .flat24 on > > > 0052 E5 82 279 mov a,dpl > > > 0054 60 04 280 jz __sdcc_init_data > > > > > > --- > > > > > > Now the "ljmp __sdcc_gsinit_startup" and "lcall __sdcc_external_startup" > > > are not in 24bit mode as earlier. > > > But the bad news is that __sdcc_external_startup is still not being > > > called (no LED control is happening as expected). > > > > > > I compiled the same hello390 program in mcs51 mode and the > > > __sdcc_external_startup in <sdcc>/device/lib/_startup.c is called > > > properly (and control reaches main function too). > > > > > > Clearly, SDCC flat24 mode for ds390 mcu is not working for me here. > > > > > > Any suggestion? > > > > > > Thanks, > > > Arif > > > > > > > > > > > > -----Original Message----- > > > From: Maarten Brock [mailto:[email protected]] > > > Sent: Wednesday, November 03, 2010 6:23 PM > > > To: [email protected] > > > Subject: Re: [Sdcc-user] SDCC DS390 Port and _sdcc_external_startup > > > > > > Yes, I noticed that after I sent my answer. I'm currently investigating > > > how it works in our regression tests. > > > > > > > > > > Thanks Maarten, > > > > > > > > BTW I sent two emails earlier and the second email contained the code > > > > from > > > > .rst file. > > > > > > > > I reached the same conclusion as you after observing .rst file but you > > > > can > > > > make a better comment after looking at that message of mine. > > > > > > > > Also, if this is the case, how can I modify SDCC code generation so that > > > > the initial 2 jump and lcall instructions are not in 24bit mode? > > > > > > > > Thanks, > > > > Arif > > > > > > > > > > > > -----Original Message----- > > > > From: Maarten Brock [mailto:[email protected]] > > > > Sent: Wednesday, November 03, 2010 5:09 PM > > > > To: [email protected] > > > > Subject: Re: [Sdcc-user] SDCC DS390 Port and _sdcc_external_startup > > > > > > > > Arif, > > > > > > > > The code you show does NOT come from the .rst file so it is impossible > > > > to > > > > check if the ljmp and lcall are in 16 or 24 bit format. From your > > > > observation that it doesn't reach _sdcc_external_startup I conclude that > > > > these first instructions use 24 bit format while the MCU is not yet in > > > > 24 > > > > bit mode. > > > > > > > > Maarten > > > > > > > >> Hello Maarten, > > > >> > > > >> The switch to 24bit flat address happens in later part of > > > >> _sdcc_external_startup function (which is not printed in this email). > > > >> I have not printed that here because I am concerned about the code > > > >> before > > > >> that i.e. > > > >> > > > >> __reset_vect: > > > >> ljmp __sdcc_gsinit_startup > > > >> __sdcc_gsinit_startup: > > > >> mov sp,#__start__stack - 1 > > > >> lcall __sdcc_external_startup > > > >> > > > >> > > > >> In __sdcc_external_startup function I switch on a LED before anything > > > >> else > > > >> like changing mode to 24bit flat24 address mode. LED control is by > > > >> writing > > > >> a bit pattern to P1 SFR. > > > >> > > > >> So after reset vector we "ljmp" to "__sdcc_gsinit_startup" then we > > > >> "lcall" > > > >> to "__sdcc_external_startup" and then we write a bit pattern to P1 SFR. > > > >> All this is done while the CPU is still *not* in flat24 address mode as > > > >> that is supposed to be done in __sdcc_external_startup > > > >> (which I am doing after LED switching on). > > > >> But as LED is not switched on. It seems control is not reaching > > > >> __sdcc_external_startup function. > > > >> > > > >> Thanks, > > > >> Arif > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> -----Original Message----- > > > >> From: Maarten Brock [mailto:[email protected]] > > > >> Sent: Tuesday, November 02, 2010 6:17 PM > > > >> To: [email protected] > > > >> Subject: Re: [Sdcc-user] SDCC DS390 Port and _sdcc_external_startup > > > >> > > > >> Arif, > > > >> > > > >> Please inspect the generated .rst files. Especially look when you > > > >> change > > > >> into ds390 mode (my guess is not at all) and when the compiler > > > >> generates > > > >> ds390 code for 24bit jump and call. > > > >> > > > >> Maarten > > > >> > > > >>> > > > >>>>> (* please forgive the top-post *) > > > >>> > > > >>>>> Arif -- > > > >>> > > > >>>>> >>> P1 = 0xFF; //ALL LEDs off > > > >>>>> >>> P1 &= (0x1<<4); //LED 4 ON > > > >>> > > > >>> > > > >>>>> Try: > > > >>>>> P1 &= ~(1<<4) ; // LED 4 on. > > > >>> > > > >>>>> your code was turning off LED4. The tilde (~) creates a bitmask > > > >>>>> that > > > >>>>> will preserve the P1 bits. They will stay off. > > > >>> > > > >>> > > > >>>>> well, it is just a guess. I am more of a Z80 programmer.... > > > >>> > > > >>> > > > >>>>> HTH, > > > >>>>> *the other brian > > > >>> > > > >>> > > > >>> > > > >>> --------------------------------------------------- > > > >>> > > > >>> Hello brian, > > > >>> > > > >>> Thanks for your response. > > > >>> > > > >>> Ah! The typo. Your observation is right. But this mistake was only in > > > >>> my > > > >>> email. The code has the correct expression (i.e. P1 &= ~(1<<4)). > > > >>> > > > >>> Also, I checked the hello390.asm file and the assembly code seems as > > > >>> expected > > > >>> ---------------------------------------------------------------------------------- > > > >>> __reset_vect: > > > >>> ljmp __sdcc_gsinit_startup > > > >>> ;-------------------------------------------------------- > > > >>> ; global & static initialisations > > > >>> ;-------------------------------------------------------- > > > >>> .area HOME (CODE) > > > >>> .area GSINIT (CODE) > > > >>> .area GSFINAL (CODE) > > > >>> .area GSINIT (CODE) > > > >>> __sdcc_gsinit_startup: > > > >>> mov sp,#__start__stack - 1 > > > >>> lcall __sdcc_external_startup > > > >>> mov a,dpl > > > >>> jz __sdcc_init_data > > > >>> ljmp __sdcc_program_startup > > > >>> ---------------------------------------------------------------------------------- > > > >>> > > > >>> > > > >>> Here, after reset __sdcc_gsinit_startup is called and then after > > > >>> adjusting > > > >>> the stack pointer; __sdcc_external_startup is called. > > > >>> > > > >>> ---------------------------------------------------------------------------------- > > > >>> ; function _sdcc_external_startup > > > >>> ; ----------------------------------------- > > > >>> __sdcc_external_startup: > > > >>> ar2 = 0x02 > > > >>> ar3 = 0x03 > > > >>> ar4 = 0x04 > > > >>> ar5 = 0x05 > > > >>> ar6 = 0x06 > > > >>> ar7 = 0x07 > > > >>> ar0 = 0x00 > > > >>> ar1 = 0x01 > > > >>> ; hello390.c:8: WTST = 0x00; > > > >>> ; genAssign: resultIsFar = FALSE > > > >>> mov _WTST,#0x00 > > > >>> ; hello390.c:9: CKCON = 0x01; > > > >>> ; genAssign: resultIsFar = FALSE > > > >>> mov _CKCON,#0x01 > > > >>> ; hello390.c:12: P1 = 0xFF; > > > >>> ; genAssign: resultIsFar = FALSE > > > >>> mov _P1,#0xFF > > > >>> ; hello390.c:13: P1 &= ~(0x1<<4); > > > >>> anl _P1,#0xEF > > > >>> -------------------------------------------------------------------------------------- > > > >>> > > > >>> The above shown code for __sdcc_external_startup seems correct too. If > > > >>> the > > > >>> control reaches here correctly, the LED must start to glow but it > > > >>> doesn't. > > > >>> So it seems the control is not reaching inside > > > >>> __sdcc_external_startup. > > > >>> > > > >>> Only suspicious thing which I can see is that __sdcc_external_startup > > > >>> is > > > >>> not in HOME seg (0x00-0x4D == 77 bytes) instead it is in CODE seg > > > >>> (s_CSEG > > > >>> == 0x008D). > > > >>> > > > >>> > > > >>> Thanks > > > >>> Arif > > > >> > > > >> > > > >> ------------------------------------------------------------------------------ > > > >> Nokia and AT&T present the 2010 Calling All Innovators-North America > > > >> contest > > > >> Create new apps & games for the Nokia N8 for consumers in U.S. and > > > >> Canada > > > >> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in > > > >> marketing > > > >> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi > > > >> Store > > > >> http://p.sf.net/sfu/nokia-dev2dev > > > >> _______________________________________________ > > > >> Sdcc-user mailing list > > > >> [email protected] > > > >> https://lists.sourceforge.net/lists/listinfo/sdcc-user > > > >> > > > >> > > > >> ------------------------------------------------------------------------------ > > > >> Achieve Improved Network Security with IP and DNS Reputation. > > > >> Defend against bad network traffic, including botnets, malware, > > > >> phishing sites, and compromised hosts - saving your company time, > > > >> money, and embarrassment. Learn More! > > > >> http://p.sf.net/sfu/hpdev2dev-nov > > > >> _______________________________________________ > > > >> Sdcc-user mailing list > > > >> [email protected] > > > >> https://lists.sourceforge.net/lists/listinfo/sdcc-user > > > >> > > > >> > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > Achieve Improved Network Security with IP and DNS Reputation. > > > > Defend against bad network traffic, including botnets, malware, > > > > phishing sites, and compromised hosts - saving your company time, > > > > money, and embarrassment. Learn More! > > > > http://p.sf.net/sfu/hpdev2dev-nov > > > > _______________________________________________ > > > > Sdcc-user mailing list > > > > [email protected] > > > > https://lists.sourceforge.net/lists/listinfo/sdcc-user > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > Achieve Improved Network Security with IP and DNS Reputation. > > > > Defend against bad network traffic, including botnets, malware, > > > > phishing sites, and compromised hosts - saving your company time, > > > > money, and embarrassment. Learn More! > > > > http://p.sf.net/sfu/hpdev2dev-nov > > > > _______________________________________________ > > > > Sdcc-user mailing list > > > > [email protected] > > > > https://lists.sourceforge.net/lists/listinfo/sdcc-user > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > Achieve Improved Network Security with IP and DNS Reputation. > > > Defend against bad network traffic, including botnets, malware, > > > phishing sites, and compromised hosts - saving your company time, > > > money, and embarrassment. Learn More! > > > http://p.sf.net/sfu/hpdev2dev-nov > > > _______________________________________________ > > > Sdcc-user mailing list > > > [email protected] > > > https://lists.sourceforge.net/lists/listinfo/sdcc-user > > > > > > > > > ------------------------------------------------------------------------------ > > > The Next 800 Companies to Lead America's Growth: New Video Whitepaper > > > David G. Thomson, author of the best-selling book "Blueprint to a > > > Billion" shares his insights and actions to help propel your > > > business during the next growth cycle. Listen Now! > > > http://p.sf.net/sfu/SAP-dev2dev > > > _______________________________________________ > > > Sdcc-user mailing list > > > [email protected] > > > https://lists.sourceforge.net/lists/listinfo/sdcc-user > > > > > > > > > > > ------------------------------------------------------------------------------ > > Centralized Desktop Delivery: Dell and VMware Reference Architecture > > Simplifying enterprise desktop deployment and management using > > Dell EqualLogic storage and VMware View: A highly scalable, end-to-end > > client virtualization framework. Read more! > > http://p.sf.net/sfu/dell-eql-dev2dev > > _______________________________________________ > > Sdcc-user mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/sdcc-user > > > > ------------------------------------------------------------------------------ > > Centralized Desktop Delivery: Dell and VMware Reference Architecture > > Simplifying enterprise desktop deployment and management using > > Dell EqualLogic storage and VMware View: A highly scalable, end-to-end > > client virtualization framework. Read more! > > http://p.sf.net/sfu/dell-eql-dev2dev > > _______________________________________________ > > Sdcc-user mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/sdcc-user > > > ------------------------------------------------------------------------------ Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev _______________________________________________ Sdcc-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sdcc-user
