This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

memory map changed

Load "C:\\Keil\\C51\\Examples\\Chipcon\\RF\\halRFtest\\halRFtest_433"
*** error 65: access violation at I:0x80 : no 'write' permission

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

Memory Map
001: I:0x00 - I:0x7F read write
002: C:0x0000 - C:0xFFFF exec read
003: X:0x000000 - X:0x00FFFF read write

error caused by Timer0 ISR trying to clear the timer
overflow flag at TCON^5, when I try to reset Memory
to what the User's Guide calls for.

0x000000 - 0x00FFFF read/write this should be IDATA that overlaps the SFR's right?
0x010000 - 0x01FFFF read/write this is XDATA
0xFF0000 - 0xFFFFFF exec read this is CODE

I have try'ed to enter the default map for small memory model using DeBug > Memory Map but keep getting
error:invalid address range given.

what could have caused the change in the memory map
and how should i change it back, please help

Calvin

Parents
  • Why would you add a long loop in an interrupt service routine? They should _always_ be optimized for speed, since that makes sure that:
    - it has finished before the next interrupt
    - you can service other interrupts without needing to nest interrupts
    - you have time left for a main loop
    - reduce lag when processing interrupts

    I'm sure that other people here can append a lot of further reasons.

Reply
  • Why would you add a long loop in an interrupt service routine? They should _always_ be optimized for speed, since that makes sure that:
    - it has finished before the next interrupt
    - you can service other interrupts without needing to nest interrupts
    - you have time left for a main loop
    - reduce lag when processing interrupts

    I'm sure that other people here can append a lot of further reasons.

Children
  • Ok I see your point, what would be a better way to
    handle a polling loop for 'Button Push' with no other
    interrupts enabled, also this polling loop happens
    only on the initial setup.

  • are you, in effect, saying that after power up somebody must push a start button - nothing else?.

    Erik

  • what would be a better way to
    handle a polling loop for 'Button Push' with no other
    interrupts enabled

    Simple. Do your polling outside 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's running time counter to determine how long the button was pressed (for debouncing purposes).

  • (for debouncing purposes).

    why bother,

    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.

    The OP need clarify NOT his code, BUT the purpose of it.

    Erik

  • Eric, actually there are 2 buttons being polled
    one cycles options the second selects the chosen
    option, the timer0 interrupt is started before entering the polling loop and select ends timer0
    and breaks; from input loop.

    What does OP stand for?????

    what about my problem-------------------------
    error 65:access violation at I:0x80 ; no"write" permission

    this should be the SFR space 0x80 - 0x7F ?
    as defined by the SMALL memory model right ?

  • the (or is it just 'my') standard means of debouncing buttons is as follows

    set a timer to interrupt at (maximum bounce time + fudge)

    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.

    error 65:access violation at I:0x80 ; no"write" permission
    two possibilities
    a) you have chosen parametres that specify a derivative with no idata (e.g. a traditional 8051)
    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 'SFR' not 'data'

    Erik

    What does OP stand for?????

    Original Poster i.e. whoever presented the problem.

  • I:0x80
    [...]this should be the SFR space 0x80 - 0x7F ?
    as defined by the SMALL memory model right ?

    No. The "I:" prefix means it'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