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?
processing is non-specific: load? run? breakpoint? acme dynamite? ALL the gory details required
Erik
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.