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
The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any other MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.
---- File information -----------
File: ds390_flat24.patch
Date: 15 Nov 2010, 10:56
Size: 1394 bytes.
Type: Unknown
ds390_flat24.patch
Description: Binary data
------------------------------------------------------------------------------ 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
