CCS/TMS570LS0714: lock() and unlock() functions being mapped to 0x0

This is what a good mapping looks like:

And this is what my mapping looks like:

The RTS source file _lock.c contains these lines ...

_CODE_ACCESS void _nop()
{
  /* Do nothing. */
}

_DATA_ACCESS void (*  _lock)() = _nop;
_DATA_ACCESS void (*_unlock)() = _nop;

These lines define the global variables _lock and _unlock, and initialize them to point to the function _nop.  I presume you use the ROM model of initialization.  In that case, startup code processes the .cinit section to initialize all the global variables, including these two.  Is there any reason to think these steps are not taking place, or somehow get messed up?

Thanks and regards,

-George

Hi George,

I appreciate your reply. You are correct in your assumption, I'm using the ROM initialization model.

Yes, I have reason to believe this step is not happening. Looking at my .map file, I see that _nop is mapped to 0x0056367. So naturally I would expect the value of _lock and _unlock to be 0x0056367.

But as I mentioned, both are initialized to 0x0. Could CLINK perhaps force these to be ignored? I've tried disabling CLINK but that's not an option for ELF outputs, which is my case.

One thing I've noticed is that in my "well-behaved" app, the barebones one that just calls srand(), has an autoinit.c.obj that I can't find in my "badly-behaved" app. How do I know for a fact that my variables are being properly initialized just by looking at logs?

Any thoughts on this?

Many thanks,

Pedro

George,

Further to what I mentioned before, I can now say that it looks like the _lock variable does *not* get initialized, as I've found this line in my UNINITIALIZED .data table, as part of my .map report:

                  08014838    00000008     rtsv7R4_T_be_v3D16_eabi.lib : _lock.c.obj (.data:$O1$$)

I don't know if you'll agree, but it does look like my _lock variable is just uninitialized for some reason. Is there any way I can force it to be initialized?

Thank you,
Pedro

Please let me know what version of the compiler tools (not CCS) you use.  If you use a fairly old version of the linker, you might be experiencing the problem discussed in this forum thread.

Thanks and regards,

-George

Hello George,

I'm using version 18.12.4.LTS of the compiler tools.

I think I'm closer to figuring this out, following your comments. Looking at sys_startup.c, generated by HalCoGen, I see that we have the following:

This #define USE_DEBUG_PROBE is necessary for us when we're in a JTAG debug session, which is exactly my case at the moment.

So it's our fault that we're not initializing the variable, since __TI_auto_init() has ended up in this #else statement. The thing is, we didn't actually place this code in there. It's only when we changed compiler tools option in HalCoGen to generate TI-compiler outputs (rather than the IAR-compiler outputs we had been using before) that this __TI_auto_init() function was appended to the code.

Can you comment on whether the ESM is required in any way to run __TI_auto_init()? I've tried moving it outside of the #ifdef statement, but then I fail initialization entirely, never getting to main().

Thank you,
Pedro

Hello again George,

The plot thickens. I've found that actually moving the __TI_auto_init() function does resolve the issue of uninitialized variables. However, as is common in our world, that problem is solved but another is created.

What I find now is that the zero-initialization of the output buffer in copy_zero_init.c ends up sending my code into an endless loop of memset instructions.