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
