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
