Problem reported in CCS version 4.1.2 and above

Sue,

I am reading through the thread.  So if I grab a 9B96 and import the \StellarisWare\boards\dk-lm3s9b96\qs-checkout\ccs example is that enough to demonstrate the problem?

Regards,

John

Hi John,

Thanks for taking a look.  The qs-checkout app only reads and writes from SDRAM, it doesn't try to execute.  You need some code that executes out of SDRAM to see the problem.

Regards,

Sue

Hi,

Thanks for taking a look at the issue. FYI, I can elaborate a bit on my code and issue.

As Sue states, to reproduce the error you need to link some code to run in the EPI memory area. For the test, I used the most simple setup i could imagine, so I added a new section called .test in the linker-file,

SECTIONS
{
....
    .test    :    > 0x60000000
.....
}

Then I added a function somewhere in a program (in my case, called after PinoutSet in the simplest helloworld-example):

#pragma CODE_SECTION(TestMe, ".test")
void TestMe()
{
    volatile unsigned int test = 2;
    test *= 2;
}

The code inside the function is simply to ensure that it is not optimized out - it could be anything. The GEL script from the thread previously mentioned is then needed to run the OnPrefileLoaded()-function and setup the EPI. You can read the rest of the behaviour in the other thread.

This was enough for me to reproduce the issue.

Thanks again,

Joachim

Aarti, your patch works perfectly, thanks.

I noticed another possible issue that I didn't mention in the first place in the other thread. This might not be the correct place to post it, but it is somewhat related.

When I compile a program where code (not data) is placed in the EPI memory area, then the linking process is extremely slow and uses 1-2 minutes to finalize linking. When no code is placed in the EPI area then the linking itself takes less than 2 sec. If only data is placed in the EPI area then there are no problems either. Even though the linking process is slow, everything works as it should, so there are no functional issues.

It seems that it is the mkhex4bin.exe that is slow, but I am not sure. I am just able to see in the console window that it freezes at the point where this binary's path is printed to the console.

I am using TMS470 CGT 4.6.4 (and CCS v. 4.2.1 as mentioned).

Can you reproduce this at all when you tried to link code to 0x60000000 ?

Thanks,

Joachim

Joachim,

Glad to hear the patch is working well.

I can reproduce the behavior where the mkhex4bin step takes a long time to complete. I played with it a little bit and it seems that if .intvecs and all initialized sections (.text, .const, .cinit, .pinit, user defined code sections) are in the same memory region, then the mkhex4bin step completely very quickly. If any of these sections are in a different memory region, then it takes longer maybe because it has more processing to do. In most cases though, I would imagine it would make sense to place all these sections in the same memory region, so hopefully it will not a big issue.

Aarti said:

In most cases though, I would imagine it would make sense to place all these sections in the same memory region, so hopefully it will not a big issue.

Perhaps, perhaps not. In my situation I wanted to find out if it is possible to to load application code to SDRAM if, in the future, the internal flash is not sufficient. This might very well become the case, because I will in 2011 have to use a communications protocol which is around ½MB in code size. The code could then be stored on a SD-card or an SSI-flash chip and loaded onto SDRAM in the beginning of the program. I would also prefer to stay with the Stellaris-platform, if it is possible. Therefore this research on SDRAM execution.

Now, if I have a library that for instance contains a communication protocol, then I might want to link this library and only this library to SDRAM, while the rest of the code is in internal flash. Thereby code is placed in many different memory areas.

Since the functional part of the mkhex4bin works, it is not a big issue, but I fear it would quickly become quite annoying if the application is constructed as mentioned. Isn't it possible to report the issue somewhere as a minor bug and hope for a future fix?

Regards,

Joachim