Remco,
I filed the bug number SDSCM00050787 today. You can check its status in the link SDOWP in my signature below.
I apologize for the inconvenience,
Rafael
Remco,
I filed the bug number SDSCM00050787 today. You can check its status in the link SDOWP in my signature below.
I apologize for the inconvenience,
Rafael
Thank you everyone for all the details an examples. I was able to track down a 5969 and can reproduce the issue. A bug has been filed - tracking ID: SDSCM00050789
thanks
ki
Hi Brad,
I filed an enhancement for this. SDSCM00050791 .
Thanks
ki
Tell them the patch they released this morning seems to be working. I am able to generate projects again.
I partly know what has gone wrong. I cannot explain exactly how it happened.
The output sections .data_sh1ram and .data_sh2ram contain near variables. Near variables are accessed at an offset from the DP register. This offset is only 15-bits wide. The linker creates the symbol __TI_STATIC_BASE based on all the sections which contain near address relocation types. In your case that is .data_sh1ram, .data_sh2ram and .bss. (The sections .neardata and .rodata are empty, or else they would act just like .bss). Your problems arise because these three output sections are not allocated within the range of a 15-bit offset.
A very technical description comes from the C6000 EABI document ...
The linker is responsible for ensuring that variables addressed using near DP-relative addressing are
placed such that they within the required 15-bit range of the DP, as established the
__c6xabi_DSBT_BASE symbol. The linker can detect such accesses as being marked by
R_C6000_SBR_* relocation entries. If the linker cannot satisfy this constraint (perhaps due to conflicting
instructions from the user), it must fail to link the program.
The symbol name __c6xabi_DSBT_BASE is the same as STATIC_BASE or __TI_STATIC_BASE.
I'm not sure of the best solution. Here are two to consider.
One ... I don't know how near data came to be in the sections .data_shr2ram and .data_sh1ram. Consider changing all that data to be far. Note you have to define and declare the data as far, and those far declarations have to visible, from a header file, everywhere else.
Two ... Change the linker command file so that the output sections .data_sh2ram and .data_sh1ram are in the same GROUP with .neardata, .rodata, and .bss.
Thanks and regards,
-George
Hello,
I have been trying to enable Neon to run Neon-VFP instructions. I have the in-line assembly ARM instructions to enable Neon :
-----------------------------------------------from TI Wiki-------------
MRC p15, #0, r1, c1, c0, #2 ; r1 = Access Control Register
ORR r1, r1, #(0xf << 20) ; enable full access for p10,11
MCR p15, #0, r1, c1, c0, #2 ; Access Control Register = r1
MOV r1, #0
MCR p15, #0, r1, c7, c5, #4 ; flush prefetch buffer because of FMXR below
; and CP 10 & 11 were only just enabled
; Enable VFP itself
MOV r0,#0x40000000
FMXR FPEXC, r0 ; FPEXC = r0
------------------------------------------------
And I included it into my my code and compiled with TI CCS5, loaded into ARM A8 memory and run it with my BeagleBone White debug mode. But first instruction, "MRC p15, #0, r1, c1, c0, #2", actually crashes the ARM.
Just wondering if this register setting instruction can cause any watchdog related reset or some other exception? Or, anything I need to run before before the this register setting instruction?
Thank you,
xyin
Naji Naufel | |||||
Sr. FAE | |||||
Avnet | |||||
naji.naufel@avnet.com | |||||
| |||||
|
xyin,
ARM cores boot in supervisor mode, therefore the initialization routine is setting it to user mode. Are you using TI's ARM compiler or GCC?
If GCC, it stays on supervisor mode by default, unless you define the symbol USERMODE in your compiler options.
If TI, it enters User mode at the very early stages of runtime initialization (at the boot.asm file). To make changes to that, check this forum thread.
Hope this helps,
Rafael
I'm using CCS 5.5.0.00077 and there is still the problem that the error list is only cleared if I do a "CLEAN PROJECT".
If I only correct the error and build the project, the .out - file is generated, but the error list window is not updated!
(it shows still the corrected error)
When will this be fixed?
Hello
I've the same problem with 'CustomShapes.scr'. I've try to convert some component to Allegro 16.5 with ultra librarian but I've all the time this error,...
I don"t know if the probleme comes from ultra librarian, Cadence or Texas,..
Regards
Laurent
Hi Sanjeev,
Could you update your CCS version? If you do not want to move to v6, at least move to CCSv5.5.
Thanks
ki
[quote user="tu kuolun"]I'm not using the startup GEL file, is there any tutorial?[/quote]
It is mentioned in slide 15 of: software-dl.ti.com/ccs/esd/training/modules/target_configurations/CCSv5-TargetConfigurations.pptx
I see you are using an older CCS version. Could you try updating your CCS version? CCSv5.5 is the latest version on the v5 stream.
Thanks
ki
[quote user="Jacob Dickinson"]I had specified the stack size as an odd number in the CCS Linker Options menu.[/quote]
The linker should handle that better. Maybe issue a diagnostic, or maybe add one to the stack size, or something. I filed SDSCM00050798 in the SDOWP system to have this addressed. Thank you for letting us know. Feel free to follow it with the SDOWP link below in my signature.
Thanks and regards,
-George
The uninstallers are under the CCS installation folder.
If you've installed in c:\ti, the 6.x uninstaller should be c:\ti\ccsv6\uninstall_ccs.exe.
I'm not sure what the 3.1 uninstaller is called, but it should be located in the CCS v3 folder as well and should say CCS in the name.
Danish
[quote user="Andy Cleeves"]
After a little more investigation I find that the problem seems to be that the function with problems are in files with "C" as the extension and not "c".
[/quote]
You are correct, that is indeed the source of the problem. Files with .C extension are treated as C++ files, hence symbol names in the object file will be different than ones for .c source files. For instance, a function named "foo" will generate the symbol name "foo" if it were a C source file, but something more mangled like "_Z3foov" if it were a C++ source file. Now since the project is mixing C and C++ source files, the referenced symbol and defined symbol names do not match up, hence the linker error.
If that source file in your project has to be C++, the way to resolve this would be use the extern "C" linkage convention to avoid the name mangling. Some info regarding name mangling and the TI compiler is here. For this specific case, if the source file does not need to be C++, the simplest solution wouldy be to ensure that all source files are .c extension.
OK, very good. Thanks!
[quote user="Jacob Dickinson"]perhaps specifying a location in RAM together with "const" are conflicting orders[/quote]
That's correct. If you use "const", then this data is placed in the .const section, an initialized section. Typically, this section is allocated to FLASH. It is possible to allocate to RAM. But that is more involved. You actually allocate to RAM for running, but to non-volatile memory (i.e. FLASH) for loading. You have to insure that, as part of system start up, the section is copied from FLASH to RAM. While there are some compiler features which make this straightforward, none of it is done automatically.
If you don't use "const", then compiler allocates it to .data. The linker collects all the .data sections together and uses that to create a section named .cinit. The system startup (or boot) routine processes the .cinit section so that the .data sections are initialized before main starts to run.
The compiler should handle this better. I filed SDSCM00050801 in the SDOWP system to have this investigated. Feel free to follow it with the SDOWP link below in my signature.
Thanks and regards,
-George
I cannot explain what is occurring based on what I see here. Please submit a test case which I can compile and see this error for myself. It does not need to run. One easy way to do it is to preprocess the source file which contains this line. I also need to know the compiler (not CCS) version and the exact compiler build options used.
Thanks and regards,
-George
Hi Burtin,
Thank you for using Webench Power Designer. The reason why you are unable to change your previous design is because of the device being turned off on the web.
Sorry for the inconvenience. We are trying to update the calculator to ensure phase margin is always above 45 degrees for this device. It might be beginning of next week that it will be back on web. I sure will notify you of the changes.
I created your design locally and now with new compensation calculations, rcomp, comp and comp2 are different. Please check the design report attached here and let me know if you have any questions.
(Please visit the site to view this file)
Regards,
Pavani Jella
WEBENCH Applications