UCD3138 will not build with CCS6.1

I've never seen that issue with CCS 6.1, but its clear what has happened - the .h files are not getting included. I can think of two reasons for this:

1. The compiler can't find the include files
2. The #include statements are missing from the .c file.

If all the files have the problem, it may be that CCS 6.1 can't find them. If it's just interrupt, then that shouldn't be the problem.

The CCS conversion tool only converts the source code. The header and linker files are in separate directories. The converted source directory needs to be in the same relationship to them as the CCS 3.3 one does. They all need to be in the same folder - like this:

- Big folder with everything
-linker files
- header files
- CCS 6 conversion generated source folder

That's my guess on what you need to fix.

I noticed another error message, about $c_int00. In the load.asm, you will see a

_c1_:
BL $c_int00

Change that to _c_int00. This change is necessary when you go to the new compiler version for 6.1.

You will also want to change interrupts.c, clear_program_flash.c, and standard_interrupt.c so that they are compiled in 32 bit (ARM) mode.

To get the $c_int00 error, you've probably changed compilers, which seems to make CCS lose track of the 32 bit mode flag.

You will generally get an error on the interrupt files, but you also need to fix clear program flash or you might not be able to clear the checksum in the flash. This may make your device into a tietack ie. not recoverable for reprogramming.

To change the mode, right click on the individual file, select show build settings, and select ARM compiler->processor options. Select 32 in the designate code state line.

Ian,

I checked the location of the header and linker file folders. Those seem to be good.

I changed

_c1_:
BL $c_int00

to

_c1_:
BL _c_int00

in load.asm and load_UCD3138.asm and that seemed to make the $c_int00 error go away.

interrupts.c, clear_program_flash.c, and standard_interrupt.c are all 32 bit code state.

interrupts.c is the only file in the project with a red error checkmark.

It seems like interrupts.c does not want to include its header files for some reason.

I assume that interrupts.c has the #includes in it, and they look like the ones in the other files?

Could there be some error in interrupts.c before the lines with the #includes that is messing things up? For some reason, CCS 6.1 doesn't sort errors by line number by default. If you click on the "Location" on the top of the column, it will do so, however, and you can check.

I guess they may be a bogus special build setting for interrupts.c. If so, it will be in the project files specifically pointing at interrupts.c, probably. If you just change the name of interrupts.c, then the special setting should disappear. You will have to go back and make it a 32 bit processor mode still, but that is something else I would try. We generally configure CCS 6.1 so it will compile any file that is in the source folder.

Hello Ian
In the other words, UCD3138 sample can migrate to CCS4.x CCS5.x via replace interrupts.c. Am I right?
Kami Huang

I haven't seen or heard of the issue you are having before this.  Converting to CCS 6 generally goes with no problems, 6.1 you need to change the compiler selection, change the $c_int00, and put the interrupt and clear program flash files back to 32 bits.  I'm just trying to figure it out with you.

If you want to zip up the files, including the header and linker directories, I'll try to take a look at it and see what's going on.

Strangely enough, when I restarted CCS6.1 this morning all the problems with interrupts.c went away.

Now there is just an error with cyclone.cmd.

"C:/../Linker Files/cyclone.cmd", line 81: error #10099-D:
program will not fit into available memory. placement with alignment fails
for section ".vectors" size 0x40 . Available memory ranges:
VECS size: 0x20 unused: 0x20 max hole: 0x20

The linker files do not need to be modified for the converted project to build right?

Hello Ian

Thanks for your kindly help. I don't need this Zip file, now. I use CCS3.3. I select CCS3.3 because TI's FAE use CCS3.3. If I have any issue, my PCB will be easy to debug. TI's FAE can duplicate to his NB. I can save some time if I get a bug. I have the other question about PFC E-Meter code. I highlight some issue about E-Meter but nobody reply, Even the answer is "I'm sorry that I don't understand what you written". Would you please tell other AE and reply the PFC E-Meter question?

Best Regards,

Kami Huang