CCS CIO errors with OMAP-L137

Hi Harri,

I have a couple suggestions here:

- Make sure you have sufficient heap and stack space. I suggest trying to make them significantly larger than they currently are just to see if it alleviates the issue, then shrinking them bit by bit until they fit in your memory map. Keep in mind that C I/O is only necessary for a Debug build, so you could specify different sizes for your Debug and Release builds.

- Always flush your C I/O buffers before reaching a breakpoint. For example, make sure you end your printf strings with a \n.

These tips and more are in this Wiki article http://tiexpressdsp.com/index.php/Tips_for_using_printf .

Thanks and regards,

-George

What I don't understand is why the exactly same project works differently on my own board which has external memory in EMIFB just like EVMOMAP (although double the size). And most of the sections go into IRAM, including .cio and printf constants, so SDRAM setup shouldn't affect them. Segment for malloc/free is in SDRAM. This really is strange. My SDRAM seems to work fine because the code resides there and runs fine. The .bss section (that's heap, right?) is also in SDRAM and I tried doubling it without any effect.

I tried changing various other things. Changing .cio to L3_CBA_RAM results in the following error set (a few less than previous):

Corrupt CIO message: buffer length (50036) > buffer size (1057).
Corrupt CIO message: buffer length (4482) > buffer size (1057).
Write error: Invalid File ID (36630) in CIO message!
Write error: Invalid File ID (36642) in CIO message!
Write error: Invalid File ID (36654) in CIO message!
Write error: Invalid File ID (36666) in CIO message!
Write error: Invalid File ID (36608) in CIO message!

Changing .cio into SDRAM results to:

The CIO command cmd:(9) in the CIO buffer at address (0xc3076c60) was not recognized. Please check the device and program memory maps.
The CIO command cmd:(255) in the CIO buffer at address (0xc3076c60) was not recognized. Please check the device and program memory maps.
The CIO command cmd:(255) in the CIO buffer at address (0xc3076c60) was not recognized. Please check the device and program memory maps.
The CIO command cmd:(101) in the CIO buffer at address (0xc3076c60) was not recognized. Please check the device and program memory maps.
The CIO command cmd:(78) in the CIO buffer at address (0xc3076c60) was not recognized. Please check the device and program memory maps.
The CIO command cmd:(42) in the CIO buffer at address (0xc3076c60) was not recognized. Please check the device and program memory maps.
The CIO command cmd:(255) in the CIO buffer at address (0xc3076c60) was not recognized. Please check the device and program memory maps.
The CIO command cmd:(101) in the CIO buffer at address (0xc3076c60) was not recognized. Please check the device and program memory maps.
The CIO command cmd:(78) in the CIO buffer at address (0xc3076c60) was not recognized. Please check the device and program memory maps.
The CIO command cmd:(77) in the CIO buffer at address (0xc3076c60) was not recognized. Please check the device and program memory maps.
The CIO command cmd:(62) in the CIO buffer at address (0xc3076c60) was not recognized. Please check the device and program memory maps.

so it has a kind of effect but nothing to lead into clues.

Then I doubled the stack size from 0x10000 to 0x20000 with no effect. A further question is, why is SDRAM declared starting from 0xc3000000 when the addres space starts from 0xc0000000?

HarriSiirtola said:

What I don't understand is why the exactly same project works differently on my own board which has external memory in EMIFB just like EVMOMAP (although double the size). And most of the sections go into IRAM, including .cio and printf constants, so SDRAM setup shouldn't affect them. Segment for malloc/free is in SDRAM. This really is strange. My SDRAM seems to work fine because the code resides there and runs fine. The .bss section (that's heap, right?) is also in SDRAM and I tried doubling it without any effect.

HarriSiirtola said:

Changing .cio into SDRAM results to: <errors>

There's no .sysmem section in the map. I always thought heap in .bss is the most common placement. What else do you think it could be?

The error address is where section .cio begins. I tested the region by writing different values and it seemed to work. Of course there may be glitches that won't show in a test like that but I doubt it because my code is running in the SDRAM flawlessly. I'll check that the speed class of the chips is sufficient.

I noticed that printing works well in non-BIOS apps (the various tests made by TI) but they use LOG_printf which is different.

My SDRAM chips are IS42S16320B-7BLI whereas EVMOMAP has IS42S16160B-6BL. So there's a slight speed difference but my 7ns chips should handle 143MHz and the gel file configures EMIFB for 133MHZ. Do you think this could still have an effect? And which timing register bits should I change in that case, to slow down EMIFB rate?

HarriSiirtola said:

There's no .sysmem section in the map. I always thought heap in .bss is the most common placement. What else do you think it could be?

Ok, that sounds more familiar. My .SDRAM$heap is in the very beginning of the SDRAM space (0xc3000000). Btw, do you know why the SDRAM start is declared there instead of beginning of ext mem space? Doesn't it waste a portion of the memory?

Which line should I change in the gel file to slow down? I think it's one of these lines:

    EMIFB_SDREF = 0         // SDRAM Refresh Control Register
        |( 0 << 31)         // Low power mode disabled
        |( 0 << 30)         // MCLK stoping disabled
        |( 0 << 23)         // Selects self refresh instead of power down
        |( 1040 <<0);       // Refresh rate = 7812.5ns / 7.5ns

    EMIFB_SDTIM1 = 0        // SDRAM Timing Register 1
        |( 25 << 25)        // (67.5ns / 7.55ns) - 1 = TRFC  @ 133MHz
        |( 2 << 22 )        // (20ns / 7.5ns) - 1 =TRP
        |( 2 << 19 )        // (20ns / 7.5ns) - 1 = TRCD
        |( 1 << 16 )        // (14ns / 7.5ns) - 1 = TWR
        |( 5 << 11 )        // (45ns / 7.5ns) - 1 = TRAS
        |( 8 <<  6 )        // (67.5ns / 7.5ns) - 1 = TRC
        |( 2 <<  3 );       // *(((4 * 14ns) + (2 * 7.5ns)) / (4 * 7.5ns)) -1. = TRRD
                            // but it says to use this formula if 8 banks but only 4 are used here.
                            // and SDCFG1 register only suports upto 4 banks.

    EMIFB_SDTIM2 = 0        // SDRAM Timing Register 2
        |( 14<< 27)         // not sure how they got this number. the datasheet says value should be
                            // "Maximum number of refresh_rate intervals from Activate to Precharge command"
                            // but has no equation. TRASMAX is 120k.
        |( 9 << 16)         // ( 70 / 7.5) - 1
        |( 5 << 0 );        // ( 45 / 7.5 ) - 1

I'm bumping this because I've done some more experimenting. I really hope someone would have the knowledge about how to setup the PLL/EMIF system for IS42S16320B-7BLI SDRAM chips so I'd have one thing less to suspect.

I noticed at least one bit field that must be changed compared to the EVMOMAP gel file:

//        |( 1 << 0 );        // 512-word pages requiring 9 column address bits
        |( 2 << 0 );        // 1024-word pages requiring 10 column address bits

I also tried to increase the delays on the lines mentioned in my previous post above, nothing changed.

Then I was confused about the first bit fields in TIM1 and TIM2 registers. The formula gives much smaller values than those in the gel file. I'd like to know why this is? The EMIFB User's Guide (SPRUFL7A) p.51 has an example where TRFC is set to 8 and TRASMAX is also 8 (that's what the formula gives).

My card passes the SDRAM test which resides in %INSTALL_DIR%\boards\evmomapl137_v1\dsp\tests\sdram. Btw, the printf calls in that test don't work correctly on the EVMOMAP board either. They print some garbage, only the calls in main() work well. Moreover, there's no change in the .cio buffer (and thus no chars on the console) until execution returns from the test function and main() prints something. Still there are many printf("\n") calls in the test function which should flush the buffer. Could this give any clues? This is easy to test because it should work similarly on any board that's known to work well.

Forget about the printf not working in the SDRAM test. Adding #include "stdio.h" in sdram_test.c alleviates that problem. The test runs fine on my board, no verify errors.

Then again, BIOS apps are a different story. And I have included stdio.h in the app I started this thread about.