Dynomotion Forum

Hi Tom,

I have a "C" program that I have been developing over the last few weeks that works perfect with a Kflop board.

I need to use a Kogna for this application, so I am attempting to port it over. I've run into several issues. I have NOT yet been been able to successfully build the code when targeting a Kogna.

I will note up front that I am making use of the optimizing TI compiler. My program implements a FAT file system and reads/writes files to a microSD card, so the optimizing compiler is important for the size of the code.

Problem #1 - strchr()
The code I am using for the FAT file system makes use of strchr(). This turns out to have some issues and differences for Kflop vs Kogna.

Kflop Behavior:
- KmotionDef.h declares "extern char *strchr(const char *_string, int _c);"
- When the program is built for Kflop, however, I *would* get a strchr() undefined symbol link error.
- To work around this, I implemented a strchr() function in my C code
- This works just find and the linker calls to my strchr() function.
- So, for Kflop I have the program working great with my own implementation of strchr()

Kogna Behavior
- When I keep my own strchr() function in code, the compiler issues a warning: symbol "strchr" being redefined.
- I can comment out my implementation and it will compile. It won't build, though.. because of problem #2 below

This doesn't seem to be a problem for me right now because I have a work-around, but thought I would share my experience.

Problem #2 - undefined symbol "__c6xabi_strasgi" during <Linking>
- With a Kflop board connected, the program compiles, downloads and runs perfectly (been doing this for weeks)
- With a Kogna board connected, the build gives an linker error (undefined symbol " __c6xabi_strasgi")

I have no idea where the __c6xabi_strasgi is coming from. Some initial web searches lead me to think it might have something to do with memcpy(). Any Ideass??
https://e2e.ti.com/support/tools/code-c ... ads-stores

Problem #3 - invalid TI_COMPILER pragma

I am also getting the following error message on attempted Kogna builds. When I get the error with Kogna, I can swap to a Kflop board, compile the exact same source and everything builds and runs just fine.
I usually have #pragma TI_COMPILER(3) as the first line of code. The snippet above was from a test when I removed the optimization level from the directive, but it doesn't matter either way .

I have multiple copies and some reduced/simplified versions of the code in different folders. Some of these copies have the problem, others don't. I'll continue to try to figure it out, but I am at a loss right now... The only think I know is I NEVER get his error when connected to a Kflop.

This is a follow up to Problem #2 in the previous post

After some more googling, it seamed more than likely that the compiler is replacing memcpy() calls with a call to __c6xabi_strasgi (and apparently the appropriate library is missing from the build chain).

I tested the theory by implementing memcpy() functionality into a function with the same name as the unresolved symbol and arguments similar to memcpy:
With this function included in my source, the target builds, links, and appears to run correctly (I can read and right to the microSD card).

I will also note here that if you make a very simple test program with only a single memcpy() call, the TI compiler WILL NOT optimize the call with a replacement to __c6xabi_strasgi. So... testing this with simple programs is troublesome.

I still need to resolve Problem #3 to be able to test in my full application. That source still gives the #pragma TI_COMPILER error

Hi Jim,

Regarding #3 invalid pargma: There is a bug where the Max Thread Space was always being compared to KFLOP's max allowed total Thread Space. When using Kogna and Thread #7 the default Thread space size (0x100000) is larger than KFLOP's total Thread space (0xb0000) which causes the error. We will correct this in the next Version.

A workaround is to specifically specify the Thread Space with:
#pragma TI_COMPILER(3, 0xb0000)

This should only be an issue when using Thread #7. Were you?

Thanks for the heads up on the workaround for the invalid pragma!!

That was driving me nuts...

This should only be an issue when using Thread #7. Were you?

Yes - I was using thread 7 for my main development, but loading other test programs in the other threads.
Super happy to now know why some programs gave the error and other didn't .

I've have added the thread space specification to the pragama and now my full program compiles and runs on Kogna.

Thanks Again!

Hi Jim,

Regarding the __c6xabi_strasgi issue: I think this is an optimized, pipelined, interruptible copy function that memcpy uses in special cases. Probably copies of sufficient size and word aligned. I was able to duplicate the problem with a simple memcpy of 1024 integers. The next version should include this function. Your C function workaround should work properly. Interestingly at Optimization level 0 the C function copied data at 9MBytes/sec where memcpy (using __c6xabi_strasgi) copied at 31MBytes/sec, but at Optimization level 3 the Compiler replaced the function call with a pipelined loop that achieved 26MBytes/sec.