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
