<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://community.arm.com/utility/feedstylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>Why the following bitwise &amp;amp; doesn&amp;#39;t work?</title><link>https://community.arm.com/developer/tools-software/tools/f/keil-forum/20021/why-the-following-bitwise-doesn-t-work</link><description> 
unsigned char tp;
unsigned char volatile pdata HOSTCFG2 _at_ 0x0020;
// HOSTCFG2=0x40 at this point
tp=HOSTCFG2 &amp;amp; 0x40;

//!!! tp is 0x00 instead of 0x40 which is expected

//Corresponding Disassembly:

C:0x08F1 7820 MOV R0,#HOSTCFG2(0x20)
C:0x08F3</description><dc:language>en-US</dc:language><generator>Telligent Community 10</generator><item><title>RE: Why the following bitwise &amp; doesn't work?</title><link>https://community.arm.com/thread/123234?ContentTypeID=1</link><pubDate>Wed, 10 May 2006 12:38:25 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:ff055475-da53-4507-a761-d3abe33149f8</guid><dc:creator>Drew Davis</dc:creator><description>&lt;p&gt;Yes.  Most tools will just pick the first symbol that matches the value that they see.&lt;br /&gt;
&lt;br /&gt;
But it doesn&amp;#39;t bother me that the symbol is CSTARTUP.  It bothers me that the immediate value in the instruction is 0000H when the _at_ keyword assigns the address 1040H.&lt;br /&gt;
&lt;br /&gt;
The code should read:&lt;br /&gt;
&lt;br /&gt;
&lt;pre&gt;
C:0x0800    900000   MOV DPTR,#SomeSymbol(&lt;b&gt;0x1040&lt;/b&gt;)
&lt;/pre&gt;&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Why the following bitwise &amp; doesn't work?</title><link>https://community.arm.com/thread/112072?ContentTypeID=1</link><pubDate>Wed, 10 May 2006 07:46:56 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:e3505750-dfd5-4570-a221-0517a3fc1c9c</guid><dc:creator>erik  malund</dc:creator><description>&lt;p&gt;I have seen quite often tha when a label match a constant, the tools pick the label.  Thus if HPWRSTATE(0x40) indeed is address 0x40 that is exactly what happens.&lt;br /&gt;
&lt;br /&gt;
Erik&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Why the following bitwise &amp; doesn't work?</title><link>https://community.arm.com/thread/98078?ContentTypeID=1</link><pubDate>Tue, 09 May 2006 22:19:16 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:117cbb8c-4ad7-4f14-96ff-9ff484f2cc81</guid><dc:creator>Drew Davis</dc:creator><description>&lt;p&gt;uVision does not automatically alter the startup code to fit the dialog box values.  Those values are used for the debugger, and some of the command-line parameters to the compiler and linker.  (See the &amp;quot;linker control string&amp;quot; box on the LX51 tab in uVision.)&lt;br /&gt;
&lt;br /&gt;
But they do not get passed in to STARTUP.A51.  You must alter that file yourself.&lt;br /&gt;
&lt;br /&gt;
Did you get a link error when building this project?  The assembler code shown is certainly wrong, since the DPTR isn&amp;#39;t being loaded with the proper address.  All zeroes makes me think that offset wasn&amp;#39;t updated.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Why the following bitwise &amp; doesn't work?</title><link>https://community.arm.com/thread/74024?ContentTypeID=1</link><pubDate>Tue, 09 May 2006 18:17:26 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:f6b9b30d-80ba-4c2f-9e0c-f39117a62ebe</guid><dc:creator>Kevin Wang</dc:creator><description>&lt;p&gt;Thanks for your quick response. I tried to move the variables from pdata space to xdata as follows. But still got similar probblems.&lt;br /&gt;
 &lt;pre&gt;
unsigned char volatile xdata HPWRSTATE _at_ 0x1040;
// In the Debug mode, the HPWRSTATE is shown to be 0x05;
if ((HPWRSTATE &amp;amp; 0x0F) ==5)
// However the above test turned out to be false; I checked the memory window X:0x1040 is 05h.

C:0x0800    900000   MOV      DPTR,#C_STARTUP(0x0000)
// Don&amp;#39;t know why the C51 couldn&amp;#39;t use the address 0x1040 here.
C:0x0803    E0       MOVX     A,@DPTR
C:0x0804    540F     ANL      A,#0x0F
C:0x0806    6405     XRL      A,#0x05
C:0x0808    701E     JNZ      C:0828
 &lt;/pre&gt;
I also tried to change the XDATASTART and XDATALEN in the STARTUP.A51, it didn&amp;#39;t work either.&lt;br /&gt;
BTW, what&amp;#39;s the difference between changing&lt;br /&gt;
XDATASTART and XDATALEN in the STARTUP.A51 AND changing the &amp;quot;Off-chip XDATA Memory Start and Size&amp;quot; configurations in Target Option windows. Which one take precedence?&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Why the following bitwise &amp; doesn't work?</title><link>https://community.arm.com/thread/46034?ContentTypeID=1</link><pubDate>Tue, 09 May 2006 16:11:21 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:712e204b-3c8d-403e-9216-f76d9ed5e60c</guid><dc:creator>Drew Davis</dc:creator><description>&lt;p&gt;The # means &amp;quot;immediate addressing&amp;quot;, which is to say a literal constant, not necessarily an address.&lt;br /&gt;
&lt;br /&gt;
In the first line, the #20H happens to be a constant used as address in the second line (MOVX).  In the third line, the #40H happens to be a constant value used in the ANL operation.&lt;br /&gt;
&lt;br /&gt;
How do you know that HOSTCFG2 is really 0x40?&lt;br /&gt;
&lt;br /&gt;
Have you checked the configuration of your pdata area to be sure it matches the hardware?  Does your hardware correctly supply the upper 8 bits of the address?&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>