Bootloader: C:0x0000 - C:0x7FFF Manages CAN-Communication and in-field update. Application C:0x8000 - C:0xEFFF Applications is controlled with bootloader over CAN 2.0. Compiled both seperatly and merge the Hex-file. Interrupts and function calls work. At level of 8 successive funtions calls the acces to an struct in Applications XDATA mem is incorrect. The expected pointer is not given. Any adwise?
you have been told again and again that your problems are related to yout total refusal to appreciate the architecture of the microcontroller you use and just push on with the function pointers that is one of the microprocessor methods which this microcontroller is incapable of. I can appreciate that Keil, to stay ANSI compliant, has somehow wrangled this functionality into the compiler, does that make it what you should use by no means Why on earth would anyone want to continue helping you when you refuse to follow advice given several times (get rid of the function pointers). "the '51 ain't no PC" got it? Erik
That's not correct. Both Projects compilied together work. The problem is the compilation of the second project. Here Startup and linker-script:
NAME FSWSTARTUP80C515 ?PR?_do_cinit?FSWSTARTUP80C515 SEGMENT CODE ?PR?_do_deinit?FSWSTARTUP80C515 SEGMENT CODE ?CO?FSWSTARTUP80C515 SEGMENT CODE PUBLIC _cinit_scn PUBLIC _do_deinit PUBLIC _do_cinit RSEG ?CO?FSWSTARTUP80C515 _cinit_scn: DB 000H,000H RSEG ?CO?FSWSTARTUP80C515 IDATALEN EQU 00H XDATASTART EQU 8000H XDATALEN EQU 6FFFH PDATASTART EQU 0H PDATALEN EQU 000H IBPSTACK EQU 0 IBPSTACKTOP EQU 0xFF +1 XBPSTACK EQU 0 XBPSTACKTOP EQU 0xFFFF +1 PBPSTACK EQU 0 PBPSTACKTOP EQU 0xFF +1 PPAGEENABLE EQU 0 PPAGE EQU 0 PPAGE_SFR DATA 0A0H ?XSIMSTACK SEGMENT IDATA RSEG ?XSIMSTACK DS 0x1 RSEG ?PR?_do_cinit?FSWSTARTUP80C515 _do_cinit: USING 0 STARTUP1: IF IDATALEN <> 0 MOV R0,#IDATALEN - 1 CLR A IDATALOOP: MOV @R0,A DJNZ R0,IDATALOOP ENDIF IF XDATALEN <> 0 MOV DPTR,#XDATASTART MOV R7,#LOW (XDATALEN) IF (LOW (XDATALEN)) <> 0 MOV R6,#(HIGH (XDATALEN)) +1 ELSE MOV R6,#HIGH (XDATALEN) ENDIF CLR A XDATALOOP: MOVX @DPTR,A INC DPTR DJNZ R7,XDATALOOP DJNZ R6,XDATALOOP ENDIF IF PPAGEENABLE <> 0 MOV PPAGE_SFR,#PPAGE ENDIF IF PDATALEN <> 0 MOV R0,#PDATASTART MOV R7,#LOW (PDATALEN) CLR A PDATALOOP: MOVX @R0,A INC R0 DJNZ R7,PDATALOOP ENDIF IF IBPSTACK <> 0 MOV ?C_IBP,#LOW IBPSTACKTOP ENDIF IF XBPSTACK <> 0 MOV ?C_XBP,#HIGH XBPSTACKTOP MOV ?C_XBP+1,#LOW XBPSTACKTOP ENDIF IF PBPSTACK <> 0 MOV ?C_PBP,#LOW PBPSTACKTOP ENDIF ;MOV SP,#?XSIMSTACK-1 ;LJMP ?C_START ?C0003: RET RSEG ?PR?_do_deinit?FSWSTARTUP80C515 _do_deinit: USING 0 ?C0004: RET END
REGFILE (..\05_out\xsim_debug.ORC) PRINT("..\05_out\xsim_debug.map") NOOVERLAY CLASSES ( XDATA (X:0x8000-X:0xF7FF, X:0xF800-X:0xFFFF), XDATA_ADL(X:0x0000 - X:0x2FFF), XDATA_HISIO (X:0x3000-X:0x3FFF), XDATA_HISFF (X:0x7000-X:0x74FF), XDATA_XSIM (X:0x8000-X:0xEFFF), CODE (C:0x8000-C:0xEFFF), CODE_ADL(C:0x0000-C:0x6AFF), CODE_HISFF(C:0x7600-C:0x7FFF), CODE_HISIO (C:0xE600-C:0xEFFF), CODE_XSIM(C:0x8100-C:0xB2FF), CONST_XSIM(C:0x8000-C:0xFFFF) )& SEGMENTS( ?CO?ADLATUS_ASWENTRYTABLE(C:0x8000), ?C?LIB_CODE(C:0x807C), ?C_INITSEG(C:0x841F), ?PR?XSIM_ASMREFRESHWDT?XSIM_ASMREFRESHWDT(C:0x8070), ?PR?XSIM_ISR_TIMER1?XSIM_INTERRUPTS(C:0x801b), ?XSIMSTACK(I:0x91) ) )
That's not correct. Both Projects compilied together work. The problem is the compilation of the second project. WHAT ON EARTH HAS "Both Projects compilied together work" to do with the fact that your use of function pointers blow "the compilation of the second project" If you took the time to get rid of the utterly stupid attitude that "C IS C" and read up on the way the '51 and the tools for it work, you would understand why you have the problem you have, the reason of which Andy has already posted twice. not really satisfying answer - "the '51 ain't no PC" got it? Of course, it can not be 'satisfying' to someone that insist on ignoring the underlying architecture. That, however does not change that it is a FACT. Erik
I'm still here. This testmain() in the applications-µVision-project works fine. Debugging information over serial port. All adresse corect.
void main(void) { tXS_ParameterPtr paramPtr; paramPtr->value[0x00u] = 0x00u; XSIM_EventDetachAll(paramPtr); while(1); }
Your use of function pointers blow "the compilation of the second project" Really? Drop the 'really and, as I suggested: read up on the way the '51 and the tools for it work. NOBODY that has "read up on the way the '51 and the tools for it work" is surprised. Erik
That's not correct. Both Projects compilied together work. When compiling separately, did you tell the linker which RAM areas it may use for each of the projects ?
Thanks Christoph for not giving up! I'm a student at work. Sorry. Telling the linker wich RAM to use for app or bootloader made in linker-script. I thought. Another idea is the initialisation of constant during startup of application. I wrapped the startup-code into c-function
do_cinit()
The possible incapacity of microcontroller is disapointing. Sorry to tell you this, but the '51 is a mix between a dinosaur, a cockroach, and a mule. A dinosaur because it's ancient and outdated and shouldn't be around anymore today. A cockroach because it's prolific and it won't go away. Even if you step on it and flush it down the toilet, it'll just crawl out of the sink again. It'll probably also be around long after you're dead and buried. A mule because it does things its way. If you want it to do anything meaningful, you need to learn what "its way" is, since it won't do anything your way. Look at the instruction set of the '51, it will tell you why the '51 architecture is badly suited for function pointers. If you have the ability to step through the program, you might be able to figure out at which point in the function the pointer becomes corrupted. Most likely it is during/after a call to sprintf or another function.
Sorry to tell you this, but the '51 is a mix between a dinosaur, a cockroach, and a mule. A very interesting biological experiment A dinosaur because it's ancient and outdated and shouldn't be around anymore today. Well, so must the Pentium be, it is an x86 processor dating equally far back as far as the roots go. A cockroach because it's prolific and it won't go away. Even if you step on it and flush it down the toilet, it'll just crawl out of the sink again. It'll probably also be around long after you're dead and buried. That proves how resilient it is, just look at how much it has mutated. A mule because it does things its way. If you want it to do anything meaningful, you need to learn what "its way" is, since it won't do anything your way. I am very happy with the way it does things, that it is intended for, it does such things beautifully The post I comment on illustrates how blatantly ignorant some are matching the application and the processor. If you want "C is C" stay with your beloved PC. I do feel sorry for you, having accepted a job that required knowledge and actual thought in the belief that your PC coding skills were applicable to '51 programming I am, honestly getting fed up with those that select the wrong processor for the job and them start whining. The '51 Is a lousy processor if you try to use it for what it is not intended for. It is a great processor if you use it for what it is intended for I know that some, who can not accept that the reason they are getting paid is that they are supposed to work, but sit back an whine "why is it not easier to program" Go ahead and put a pentium in a $2 toy it is, after all easy to program, I wish you great success with your business. Erik
I am very happy with the way it does things, that it is intended for, it does such things beautifully No one would expect a racehorse to do the work of a mule, or vice versa. The post I comment on illustrates how blatantly ignorant some are matching the application and the processor. Whoaaa ... wait a minute. Easy on the coffee, maybe try decaf ? I'm not the one who's trying to do floating point math in an ISR, or implement paged virtual memory on a '51, or juggling function pointers around. My '51 project works just fine, and the MCU is quite suited for the task I have. If you want "C is C" stay with your beloved PC. I haven't programmed on a PC in, uh, years, and nothing I ever did on a PC was even close to a commercial project. I started directly with DSPs and uCs, and my very first project was pretty much pure assembly, except for some boring clerical parts that were easier to do in C.
@Erik: Very nice and smart comments, although you are right. The post I comment on illustrates how blatantly ignorant some are matching the application and the processor. I think one of the biggest challenges in embedded software development is the goal to build cross platform software efficient in size and speed, that is modular and maintainable. You often do not have the choice of the platform and have to make things going. You lucky, seems you lack that experience. I am, honestly getting fed up with those that select the wrong processor for the job and them start whining. I am fed up with people beeing so smart and and having no clue about real life. Its not always your nice little electronic playground in the basement. And if somebody is - like Micheal admitted - still a student who has to deal with this problem he obviously didn't choose, it is really nice helping him out. If you dont want to help him - leave it - but stop nagging around. And by the way, the person whining around is not him! cheerz
"I think one of the biggest challenges in embedded software development is the goal to build cross platform software..." I don't think that is generally a significant goal in embedded development at all! Generally, the task of an embedded system is so closely linked to its specific hardware platform that any effort at making it "portable" is largely pointless! Of course, there are some parts of an embedded system that can benefit from portability - comms protocols is one that springs to mind. "You often do not have the choice of the platform..." See above - the platform will usually have been chosen to be suited to the application. "a student who has to deal with this problem he obviously didn't choose" Is it obvious that he didn't choose it? If he didn't, it is indeed a shame that he's been given an inapproriate target, and/or inadequate guidance in using it; If he did, it is a shame that he's been given inapproriate and/or inadequate guidance in his choice. Oh well, he's probably learned something about selecting an appropriate target byt now...!
"a student who has to deal with this problem he obviously didn't choose" hold your horses, are you saying that somebody else told him to use function pointers? In my response to the "the '51 is a piece of $#!^' post I addressed a number of issues, and I think one thing has been lost: I did not say "what he wants to do can not be done with a '51", I said "what he wants to do can not be done applying PC coding style to a '51". Erik
hold your horses, are you saying that somebody else told him to use function pointers? I'd guess he probably "inherited" the software from someone else. How else could it happen that he already has a really large piece of software and only then finds out that some fairly basic functionality is missing ?
I am, honestly getting fed up with those that select the wrong processor for the job and them start whining. Its not always your nice little electronic playground in the basement. I wish I could have the income I have from my job, in "my nice little electronic playground" That would be luvverly. However, since I work with this 8+ hours a day I do not have a "nice little electronic playground" there are other things in life. And if somebody is - like Micheal admitted - still a student who has to deal with this problem he obviously didn't choose, it is really nice helping him out. If you dont want to help him - leave it - but stop nagging around. I have tried and tried to help him, but what has his response been to my helpful hint "get rid of function pointers"? Erik
My '51 project works just fine, and the MCU is quite suited for the task I have. I am amazed you achieved that with a cross between a dinosaur, a mule and a cockroach. Erik