We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I'm currently running a SiLabs C8051F336 processor using the CX51 compiler. I'm getting and illegal op-code (A5-the EMOV instruction) when I compile the following line:
*string = map_char_to_index(*string, font);
this get compiled as
; SOURCE LINE # 77 001E AD00 R MOV R5,font 0020 120000 R LCALL _map_char_to_index 0023 AB00 R MOV R3,string 0025 AA00 R MOV R2,string+01H 0027 A900 R MOV R1,string+02H 0029 EF MOV A,R7 002A A558 EMOV @PR0,A
Any ideas as to why that instruction is implemented on a non MX core, and non Phillips device? How do I disable it?
Okay, sorry that was my bad on using the CX51 compiler.
I have switched to the C51 compiler and the LX51 linker, which I believe is correct. However, I'm still running into problems now.
1) I am using userclasses in my project, following is the C code
#pragma userclass (code = SERVO)
I'm not getting any compiler errors/warnings.
Then I link with the following option
LX51 ... CLASSES ( CODE_SERVO (C:0x600 - C:0x3A00) )
And I get the error
*** WARNING L47: NO SEGMENTS ASSIGNED TO USER CLASS CLASS: CODE_SERVO
Any suggestions?
2) Upon downloading using the SILabs IDE, it crashes when processing OMF file. I realize this isn't a Keil product, but has anyone seen or dealt with this issue?
Thanks, Steve
Upon downloading using the SILabs IDE, it crashes when processing OMF file. I realize this isn't a Keil product, but has anyone seen or dealt with this issue?
Are you using the SILabs as a standalone or through Keil?
processing is non-specific load? run? breakpoint? acme dynamite? ALL the gory details required
Erik
Yes I am using the stand alone SiLabs IDE V3.61
processing is non-specific: load? run? breakpoint? acme dynamite? ALL the gory details required
I'm sorry I didn't quite understand what you meant by that statement...
When I compile, I get the issues stated above. No errors though, so I proceed to download to the F336. Once I initiate this and the IDE comes up with the status box it locks up first thing on the "processing OMF file" dialog. Windows then takes over and gives me a force close.
I'd have to say it's along the lines of acme dynamite at this point.
and whatever else you can think of to elaborate on the problem.
more words do not make you appear stupid, they make you appear precise.
SiLabs process for loading code into the UC.
Compile & link
Connect to Device
Download -- at this point a status dialog appears there are several steps in this process. 1) processing OMF file... 2) writing flash blocks... 3) verifying flash blocks... 4) updating system information...
disconnect and run like the wind... ideally
I'm using my own board design. Which will program & run just dandy when I exclude the function call containing the EMOV instruction.
I am using the USB debug adapter, programming using the 3 wire method.
Windows Vista.
If I compile and run the source using C51 and LX51 WITHOUT specifying memory locations(#pragma), it will program and the chip will run with out issue.
Once I define specific memory locations it crashes on me.
Switching to BL51 does not work because it doesn't like the SEGMENTS keywords and such that LX51 is accustomed to.
We have been using CX51 with LX51 because we needed the memory location functions of LX51 and we naively assumed CX51 would be needed with LX51.
This issue has been resolved. The problem was with the compiler (C51) not passing along the #pragma userclass directive to the linker.
In order to use C51 with LX51 the OMF2 command line arg. must be used.
This resolved the crashing issues with SiLabs IDE also.
That's not quite true.
You can use C51 with LX51 without the OMF2 control provided you don't want to use any of the features that require OMF2!
eg, the documentation of the USERCLASS Compiler Directive says,
"Memory classes are only available when you use the OMF2 format and the extended LX51 Linker/Locater."
http://www.keil.com/support/man/docs/c51/c51_userclass.htm
At this point I believe all the fly *** has been removed from the pepper. Moving along now.