<?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>memory map changed</title><link>https://community.arm.com/developer/tools-software/tools/f/keil-forum/20670/memory-map-changed</link><description> 
Load
&amp;quot;C:\\Keil\\C51\\Examples\\Chipcon\\RF\\halRFtest\\halRFtest_433&amp;quot; 
*** error 65: access violation at I:0x80 : no &amp;#39;write&amp;#39; permission 

 
616: INT_SETFLAG(INUM_TIMER0,INT_CLR); 
C:0x13BF C28D CLR TF0(0x88.5) 

 
Memory Map 
001: I:0x00 - I:0x7F read</description><dc:language>en-US</dc:language><generator>Telligent Community 10</generator><item><title>RE: memory map changed</title><link>https://community.arm.com/thread/141786?ContentTypeID=1</link><pubDate>Fri, 29 Jun 2007 13:05:25 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:7848bc61-7fe2-47d3-97d1-60f60ea9bedc</guid><dc:creator>HansBernhard Broeker</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;I:0x80&lt;br /&gt;
[...]this should be the SFR space 0x80 - 0x7F ?&lt;br /&gt;
as defined by the SMALL memory model right ?&lt;br /&gt;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
No. The &amp;quot;I:&amp;quot; prefix means it&amp;#39;s IDATA, not SFRs. What this means is
that your debugger memory map is set up for a real 128-byte RAM 8051
device, but your program was built to run on a bigger (256-byte)
variant. One of the two is wrong. You figure out which. Pay special
attention to your startup code&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: memory map changed</title><link>https://community.arm.com/thread/141790?ContentTypeID=1</link><pubDate>Fri, 29 Jun 2007 06:54:52 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:5037c8d2-5c94-42fb-a804-7a2b42060aad</guid><dc:creator>erik  malund</dc:creator><description>&lt;p&gt;&lt;p&gt;
the (or is it just &amp;#39;my&amp;#39;) standard means of debouncing buttons is
as follows&lt;/p&gt;

&lt;p&gt;
set a timer to interrupt at (maximum bounce time + fudge)&lt;/p&gt;

&lt;p&gt;
In the ISR read the buttons and only report the change (to a
global variable) if the button has read the same two consqutive
times. Then, in the main act upon that global variable.&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;error 65:access violation at I:0x80 ; no&amp;quot;write&amp;quot;
permission&lt;/i&gt;&lt;br /&gt;
two possibilities&lt;br /&gt;
a) you have chosen parametres that specify a derivative with no idata
(e.g. a traditional 8051)&lt;br /&gt;
b) you are trying to (re)set SFRs or SFR bits with syntax not
acceptable to Keil. e.g. a SFR must be defined as &amp;#39;SFR&amp;#39; not
&amp;#39;data&amp;#39;&lt;/p&gt;

&lt;p&gt;
Erik&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;What does OP stand for?????&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Original Poster i.e. whoever presented the problem.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: memory map changed</title><link>https://community.arm.com/thread/138474?ContentTypeID=1</link><pubDate>Thu, 28 Jun 2007 21:33:05 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:3060d3d8-ebd0-453a-8ae7-0e10b69589c5</guid><dc:creator>calvin walker</dc:creator><description>&lt;p&gt;&lt;p&gt;
Eric, actually there are 2 buttons being polled&lt;br /&gt;
one cycles options the second selects the chosen&lt;br /&gt;
option, the timer0 interrupt is started before entering the polling
loop and select ends timer0&lt;br /&gt;
and breaks; from input loop.&lt;/p&gt;

&lt;p&gt;
What does OP stand for?????&lt;/p&gt;

&lt;p&gt;
what about my problem-------------------------&lt;br /&gt;
error 65:access violation at I:0x80 ; no&amp;quot;write&amp;quot; permission&lt;/p&gt;

&lt;p&gt;
this should be the SFR space 0x80 - 0x7F ?&lt;br /&gt;
as defined by the SMALL memory model right ?&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: memory map changed</title><link>https://community.arm.com/thread/135030?ContentTypeID=1</link><pubDate>Thu, 28 Jun 2007 15:32:26 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:04233a55-fd50-4aec-a0d1-4a411900c8b3</guid><dc:creator>erik  malund</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;(for debouncing purposes).&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
why bother,&lt;/p&gt;

&lt;p&gt;
if the issue is to see the button pressed at start (the OP mention
nothing else) and the button has no other purpose, there is no
reason, whatsoevet to debounce it.&lt;/p&gt;

&lt;p&gt;
The OP need clarify NOT his code, BUT the purpose of it.&lt;/p&gt;

&lt;p&gt;
Erik&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: memory map changed</title><link>https://community.arm.com/thread/123888?ContentTypeID=1</link><pubDate>Thu, 28 Jun 2007 14:49:41 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:8b4a186b-46e8-4dea-899f-ad3dc9ec2ef5</guid><dc:creator>HansBernhard Broeker</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;what would be a better way to&lt;br /&gt;
handle a polling loop for &amp;#39;Button Push&amp;#39; with no other&lt;br /&gt;
interrupts enabled&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Simple. Do your polling &lt;b&gt;outside&lt;/b&gt; the ISR. The timer ISR
should do nothing but count up time. The polling loop can then go on
to check the state of that button, and use the ISR&amp;#39;s running time
counter to determine how long the button was pressed (for debouncing
purposes).&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: memory map changed</title><link>https://community.arm.com/thread/123887?ContentTypeID=1</link><pubDate>Thu, 28 Jun 2007 13:42:52 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:7cd249bb-269d-4bac-bf25-9f9144f8bc53</guid><dc:creator>erik  malund</dc:creator><description>&lt;p&gt;&lt;p&gt;
are you, in effect, saying that after power up somebody must push
a start button - nothing else?.&lt;/p&gt;

&lt;p&gt;
Erik&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: memory map changed</title><link>https://community.arm.com/thread/112962?ContentTypeID=1</link><pubDate>Thu, 28 Jun 2007 13:34:59 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:00d40aff-999b-4a10-a8a1-18d0d76a6d2f</guid><dc:creator>calvin walker</dc:creator><description>&lt;p&gt;&lt;p&gt;
Ok I see your point, what would be a better way to&lt;br /&gt;
handle a polling loop for &amp;#39;Button Push&amp;#39; with no other&lt;br /&gt;
interrupts enabled, also this polling loop happens&lt;br /&gt;
only on the initial setup.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: memory map changed</title><link>https://community.arm.com/thread/99336?ContentTypeID=1</link><pubDate>Thu, 28 Jun 2007 03:46:58 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:3f2c73c7-b941-4a4d-b01a-d172d3927de2</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
Why would you add a long loop in an interrupt service routine?
They should _always_ be optimized for speed, since that makes sure
that:&lt;br /&gt;
- it has finished before the next interrupt&lt;br /&gt;
- you can service other interrupts without needing to nest
interrupts&lt;br /&gt;
- you have time left for a main loop&lt;br /&gt;
- reduce lag when processing interrupts&lt;/p&gt;

&lt;p&gt;
I&amp;#39;m sure that other people here can append a lot of further
reasons.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: memory map changed</title><link>https://community.arm.com/thread/75201?ContentTypeID=1</link><pubDate>Wed, 27 Jun 2007 19:48:56 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:17a7515a-d757-44f3-ba3a-7628cec17edc</guid><dc:creator>calvin walker</dc:creator><description>&lt;p&gt;&lt;p&gt;
Thanks for the response, I have modified the&lt;br /&gt;
halRFtest_full example program to function with my&lt;br /&gt;
prototype circuit the error 65 happens in a ISR used&lt;br /&gt;
to flash LEDs in the background while polling for&lt;br /&gt;
user input this code worked fine untill I expanded&lt;br /&gt;
my code, have I voilated some restriction?&lt;/p&gt;

&lt;p&gt;
void TIMER0_ISR() interrupt INUM_TIMER0&lt;br /&gt;
{ int i;&lt;br /&gt;
INT_SETFLAG(INUM_TIMER0,INT_CLR);&lt;br /&gt;
ISR_TIMER0_ADJUST(tCounter);&lt;br /&gt;
for(i=0;i&amp;lt;30000;i=i+1)&lt;br /&gt;
{ }&lt;br /&gt;
P0_0=~P0_0;&lt;br /&gt;
P2_4=~P2_4;&lt;br /&gt;
}// End Timer0 ISR&lt;/p&gt;

&lt;p&gt;
compiling halRFtest.c...&lt;br /&gt;
HALRFTEST.C(161): warning C260: &amp;#39;=&amp;#39;: pointer truncation&lt;br /&gt;
linking...&lt;br /&gt;
Program Size: data=99.2 xdata=186 const=39 code=5296&lt;br /&gt;
creating hex file from &amp;quot;halRFtest_433&amp;quot;...&lt;br /&gt;
&amp;quot;halRFtest_433&amp;quot; - 0 Error(s), 1 Warning(s).&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: memory map changed</title><link>https://community.arm.com/thread/48245?ContentTypeID=1</link><pubDate>Sun, 17 Jun 2007 07:33:24 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:a59ed39f-027e-4b10-8d06-09326cc92613</guid><dc:creator>HansBernhard Broeker</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;when I try to reset Memory to what the User&amp;#39;s Guide calls
for.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
I&amp;#39;m reasonably sure no User&amp;#39;s Guide applicable to Keil C51 calls
for &lt;b&gt;that&lt;/b&gt; memory map. You&amp;#39;ve mixed up memory spaces
(code,data,idata,xdata) and their internal encoding for generic
pointers. The debugger uses prefixes to indicate memory spaces. And
no &amp;#39;51 on this planet has a DATA space going up all the way to
0xffff.&lt;/p&gt;

&lt;p&gt;
You&amp;#39;ve also misinterpreted the error message. It is not about the
machine instruction you&amp;#39;ve shown. It&amp;#39;s about an instruction using
indirect access to address 0x80 --- probably the one directly before
the one you&amp;#39;ve shown. The reason for that is perfectly clear from the
memory map as shown: you configured the tools to believe your chip
has only 128 bytes of internal RAM --- a property that&amp;#39;s pretty much
nonexistant in today&amp;#39;s &amp;#39;51 controllers.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>