This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
There are no assembler errors reported in Problem tab for ARM TI 4.4.16 compiler. Only C file errors are listed. All three TI error parsers are enabled by default.
The output of compiler is
"D:\Test_0\sp5 ccsv4 test\m3\app\os\.\..\..\..\shared\common\os\source\xdiv_thumb_test.asm", ERROR! at line 27:
[E0002]
Condition codes not allowed outside of IT blocks in Thumb.
LDRBEQ R1, [R0]
1 Assembly Error, No Assembly Warnings
Eugene
Eugene,
Not entirely sure what is your question and/or if you are developing in assembly, but I've seen somewhere (I can't remember, though) that LDR/STR instructions should be written in the form LDR/STR <condition> <size>. In this case it seems the instruction should be LDREQB instead of LDRBEQ.
Since the error mentions Thumb, the quick start guide below has a note at page 6 (inside the table "Condition Field") that mentions the only Thumb instruction that can have a condition code is B (branch).
http://infocenter.arm.com/help/topic/com.arm.doc.qrc0001l/QRC0001_UAL.pdf
However, by looking at your path I guess you are trying to build for M3 (which uses Thumb-2 and the above limitation does not apply). In this case, please make sure you are using the -mv7M3 -mt options. Also, you could try to use a newer assembler (CCSv4 ships with 4.5.1) and try to rule out any bug that may have been fixed in a newer release.
Hope this helps,
Rafael
Rafael,
My note is not about assembly error or validity of a particular mnemonic. The error in the example is intentional and places LDRBEQ outside of IT block in T2 to force assembler to generate error message.
The issue is with CCSv4 TI ASM Error Parser. CCSv4 does not seem to recognize error message from TI ARM assembler it is not listed under problems tab. I wonder if it is problem with the error parser or something else is in there.
Eugene
Eugene,
As per your description it seems the IDE is not picking errors from the assembler. Do you have the source code (or a stripped down version of your code) that could reproduce this error? This way it would be quicker to investigate and potentially fix this issue.
Thank you for reporting this,
Rafael
This is easily reproducible. Just modify any assembly source file so as to generate a error and the error will not be listed in the Problems window like it does for C/C++ source files. The error only appears in the Console window. Not sure if there is a setting somewhere to change this. I will poke around a bit and if I don't find anything, will submit a bug report.
Aarti,
I couldn't reproduce this issue with MSP430 assembler (check attached jpg). I don't have a handy ARM assembly file here with me... If you can file this bug, that would be great!
Thank you,
Rafael
Rafael,
I don't see the issue with newly created projects as well. But I have some projects migrated from CCS 3.3 in my workspace where I can duplicate the behavior, so its really odd. I haven't yet been able to pinpoint what is causing the problem though, but I will submit a bug.
Eugene, is yours a project migrated from CCS 3.3?
No, it is created from scratch as SDT make project through command line.
There also other strange behavior related to parsers.
1. When file opened through the File->Open dialog it is not color coded or parsed at all
2. If *.gel extension is associated with C parser in file types it is not parsed or color coded when opened through GEL files tab. It is parsed if it is opened in the project where it is a linked resource.
I wonder if it might be common problem.
Eugene
Eugene,
We're still investigating the assembler parser issue, since it seems to affect files linked to projects instead of added (where the file itself is copied to the main project directory).
With regards to the issue with the syntax highlighting you mentioned, I could not reproduce it at all in CCS 4.0.1. Either ASM, C or GEL opened inside a project or using File->Open were correctly parsed and color-coded. Just as a cleanup check, can you do one of the steps below?
- Try to reset the perspective (menu Window -> Reset Perspective), this usually repairs IDEs misbehaviour
- Open the files in a different workspace (maybe one of the properties of the current one is invalid)
- Make sure you have all the associations in place (menu Window -> Preferences -> General -> Content Types). Check the attached JPG where I added the GEL syntax highlighting support.
Unfortunately I don't have any additional details on why this may not be working. Without being able to reproduce the issue it becomes a bit difficult to investigate the possibilities.
Hope this helps,
Rafael
desouza said:Eugene,
We're still investigating the assembler parser issue, since it seems to affect files linked to projects instead of added (where the file itself is copied to the main project directory).
With regards to the issue with the syntax highlighting you mentioned, I could not reproduce it at all in CCS 4.0.1. Either ASM, C or GEL opened inside a project or using File->Open were correctly parsed and color-coded. Just as a cleanup check, can you do one of the steps below?
- Try to reset the perspective (menu Window -> Reset Perspective), this usually repairs IDEs misbehaviour
E: I did try this with no change!
- Open the files in a different workspace (maybe one of the properties of the current one is invalid)
E: This is not applicable to my use case as workspaces are created new from command line as SDT make projects
- Make sure you have all the associations in place (menu Window -> Preferences -> General -> Content Types). Check the attached JPG where I added the GEL syntax highlighting support.
E: I did this and my WS preferences under content types looks like your example. It did not change anything. To gel color coding I have to include file into project under WS. File->Open is still BW. FYI, I can not get color coding on linker command files with *.cmd at all. Even when they are part of the project and even with mapping them to C files.
Unfortunately I don't have any additional details on why this may not be working. Without being able to reproduce the issue it becomes a bit difficult to investigate the possibilities.
E: I can provide test case.
Hope this helps,
Rafael