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
when I try to reset Memory to what the User's Guide calls for.
I'm reasonably sure no User's Guide applicable to Keil C51 calls for that memory map. You'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 '51 on this planet has a DATA space going up all the way to 0xffff.
You've also misinterpreted the error message. It is not about the machine instruction you've shown. It's about an instruction using indirect access to address 0x80 --- probably the one directly before the one you'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's pretty much nonexistant in today's '51 controllers.
Thanks for the response, I have modified the halRFtest_full example program to function with my prototype circuit the error 65 happens in a ISR used to flash LEDs in the background while polling for user input this code worked fine untill I expanded my code, have I voilated some restriction?
void TIMER0_ISR() interrupt INUM_TIMER0 { int i; INT_SETFLAG(INUM_TIMER0,INT_CLR); ISR_TIMER0_ADJUST(tCounter); for(i=0;i<30000;i=i+1) { } P0_0=~P0_0; P2_4=~P2_4; }// End Timer0 ISR
compiling halRFtest.c... HALRFTEST.C(161): warning C260: '=': pointer truncation linking... Program Size: data=99.2 xdata=186 const=39 code=5296 creating hex file from "halRFtest_433"... "halRFtest_433" - 0 Error(s), 1 Warning(s).
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.
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
View all questions in Keil forum