Problem with I2C Sample on ARM9 of OMAP-L138

Stefan Koehler

Other Parts Discussed in Thread: OMAP-L138, SYSBIOS, TCA6416, OMAPL138, TMS320C6452

Hi,

I want to use my ARM9 on the OMAP-L138 to do peripheral work such as sending/receiving I2C/SPI/UART messages, while the DSP calculates stuff and communicates via MessageQ with the ARM side. For the I2C/SPI/UART driver EDMA is used and therefore I downloaded the EDMA LLD as well.

My RTSC setup:

XDCtools version 3.20.8.88
EDMA3 ow Level Driver (2.11.0)
Inter-processor Communication (1.22.5.27)
PSP DRIVERS (2.10.1)
SYS/BIOS (6.31.4.27)

Now I've got the following problem: The Sample Code for ARM9 executes when the platform ti.platforms.evmOMAPL138 is selected. I need different memory mappings though to perform Inter Process Communication between the processors, therefore I want to use the platform ti.sdo.ipc.examples.platforms.evmOMAPL138.arm and the .dsp version which are provided by the IPC Multiprocessor MessageQ example. With this platform I'm getting an assertion.

1) As said the I2CSample project works with ti.platforms.evmOMAPL138.

2) I2CSample project doesn't work with ti.sdo.ipc.examples.platforms.evmOMAPL138.arm I get the following assertion during a Stream_write(...):

CONSOLE:
EDMA driver initialization PASS.
I2C Sample Application
I2C :Start of I2C sample application
Stream_create(outHandle) returned status = 0
Stream_create(inHandle) returned status = 0
I2C exapnder/LEDs write/read test started
ti.psp.i2c.I2c: line 2688: E_timeOut: Error in Timeout
ti.sysbios.gates.GateMutex: line 114: assertion failure: A_badContext: bad calling context. See GateMutex API doc for details.
xdc.runtime.Error.raise: terminating execution

There is not much difference in the platform files. Only in the memory mapping of the ARM program code (using 0xC3000000 for 1) and using 0xC0000000 for 2), which seems to be the only difference I see).

The I2C Example includes

var Edma = xdc.loadPackage("ti.sdo.edma3.drv.sample");

This package (...\Texas Instruments\edma3_lld_02_11_01_02\packages\ti\sdo\edma3\drv\sample) includes the initialization of the EDMA3 and has plenty of code referring to and handling platform names of which I'm not sure what exactly is done. Maybe this is a starting point but it's only a guess.

Thanks for any help on this,
Stefan

over 14 years ago

0 Raghavendra Maddikery over 14 years ago

TI__Expert 5500 points

Hi Stefan,

'E_timeOut' is an error raised from the I2C driver itself. A timeout value of (0x000FFFFFu) is set to break the operation because of any hardware limitations.

Stefan Koehler said:
I2CSample project doesn't work with ti.sdo.ipc.examples.platforms.evmOMAPL138.arm I get the following assertion during a Stream_write(...)

In this case,Since you are using platforms from ipc, I would like you to do few experiments.

1. In i2cSample_main.c file place a breakpoint at configureI2c(...) function and step through. This will take you to (pspdrivers\pspdrivers_\packages\ti\psp\platforms\evmOMAPL138\src\) i2c_evmInit.c file where the pinmux related settings for i2c is done. Here, check if the values are getting set appropriately.

2. What is the result when you set platforms to ti.sdo.ipc.examples.platforms.evmOMAPL138.dsp? and please check if this is working on dsp?. If it is working on dsp, then we can suspect that this issue is related to ARM. This might be because, in ARM the MMU is enabled. You can refer to mmu.cfg file (placed in: pspdrivers\pspdrivers_\packages\ti\psp\platforms\evmOMAPL138\). Here we disable cache for certain sections of peripheral memory ranges. This might conflict with the memory map you are choosing and possibly lead to certain code memory getting cached and raise issues.

3. Related to EDMA, In the i2cSample.cfg file(placed in: pspdrivers_02_10_01\packages\ti\psp\examples\evm6748\i2c\config\), line 46: change i2cPrms.opMode from I2c.OpMode_DMAINTERRUPT to I2c.OpMode_INTERRUPT and check if this is working fine.

Please try this and let us know the results..

Thanks & regards,

Raghavendra

0 Stefan Koehler over 14 years ago in reply to Raghavendra Maddikery

Intellectual 525 points

Hi Raghavendra,

Thanks for your time!

First I'd like to give some additional information which i did forget to mention:

First of all since I'm using not the EVM but a custom board (with only a few LEDs and Pinheaders) which holds the Logic PD SOM-M1 I don't have the TCA6416 connected to I2C0.That's why I get a timeout even for correct operation, since there is not device to answer the I2C configure request. This timeout with the ti.platform.evmOMAPL138 is
EDMA driver initialization PASS.
I2C Sample Application
I2C :Start of I2C sample application
Stream_create(outHandle) returned status = 0
Stream_create(inHandle) returned status = 0
I2C exapnder/LEDs write/read test started
ti.sdo.io.Stream: line 482: E_timeOut: Error in Timeout (<- is expected to raise)

Some more information to prevent inconsistence:
- I import ..\Texas Instruments\pspdrivers_02_10_01\packages\ti\psp\examples\evmOMAPL138_arm\i2c. Both I2CSample + I2CSample_Configuration.
- I set:
i2cSample_io.c
line 274: dataBuffer.bufLen = 1u; (originally it was 2)
since noone can answer the request and I would stay in Idle otherwise
(sorry for doing this mess in the code but I don't have the TCA6416 on my custom board)
- The code works for ti.platforms.evmOMAPL138

I did the experiments you propsed:

1)

The PINMUX is set correctly to I2C0 according to the OMAPL138 Processor Reference Guide (sprugm7d.pdf)

2)

I can not choose the Platform ti.sdo.ipc.examples.platforms.evmOMAPL138.dsp since this is a ARM project. I imported ..\Texas Instruments\pspdrivers_02_10_01\packages\ti\psp\examples\evmOMAPL138\i2c though which is the DSP equivalent example project. I changed again the line which specifies the bufLength. I used the ti.platform.evmOMAPL138 first, then rebuild after selecting ti.sdo.ipc.examples.platforms.evmOMAPL138.dsp. Both executables give me the same (correct) output
(...)
I2C exapnder/LEDs write/read test started
ti.sdo.io.Stream: line 482: E_timeOut: Error in Timeout

Regarding the MMU:
I use (on the ARM side) 0xC3000000 with ti.platforms.evmOMAPL138 (which works) and 0xC0000000 for ti.sdo.ipc.examples.platforms.evmOMAPL138.dsp (which doesn't work) both of which are defined in the same way as far as I understand MMU.cfg:
for (var i= 0xC0000000; i < 0xE0000000; i = i + 0x0100000)
{
    attrs.bufferable = true;
    attrs.cacheable = true;
    Mmu.setFirstLevelDescMeta(i, i, attrs);
}

I commented out the loading of the capsule MMU.cfg in i2cSample.cfg and disabled MMU/Cache
/* Load the MMU cfg file                                                      */
//xdc.loadCapsule("ti/psp/platforms/evmOMAPL138/mmu.cfg");
var Cache = xdc.useModule('ti.sysbios.family.arm.arm9.Cache');
var Mmu    = xdc.useModule('ti.sysbios.family.arm.arm9.Mmu');

/* Enable the cache                                                           */
Cache.enableCache = false;

/* Enable the MMU (Required for L1 data caching)                              */
Mmu.enableMMU = false;

The problem stays the same!

3)(cache is enabled again for this experiment)

with I2c.OpMode_INTERRUPT I stay in the Idle loop unless I change the following line

size = Stream_write(i2c_outHandle,&dataBuffer,(SizeT)dataBuffer.bufLen,BIOS_WAIT_FOREVER,eb);
to
size = Stream_write(i2c_outHandle,&dataBuffer,(SizeT)dataBuffer.bufLen,50,eb);
then I get a (correct) timeout :
...
I2C exapnder/LEDs write/read test started
ti.sdo.io.Stream: line 442: E_timeout: Timeout
ti.sdo.io.Stream: line 442: E_timeout: Timeout

So it really seems to be a problem with the EDMA driver then, right?

4)

I tried to make a new platform now using exactly the same name: "ti.platforms.evmOMAPL138" with 0xC0000000 as DDR memory settings in an own repository (I did this to make sure it's not the platform name messing things up). This causes again the same assertion as before.

Now... what heavily confuses me... I changed the memory to the same es in the original ti.platforms.evmOMAPL138 (0xC3000000) and I got the error as well.

The only difference between my ti.platforms.evmOMAPL138 platform to the original one is that the original one includes DSP and ARM(GPP) in one platform file (I didn't know to create such a platform, so I just copied the ARM(GPP) part of it).

Thanks for the help,
Stefan

0 Stefan Koehler over 14 years ago in reply to Stefan Koehler

Intellectual 525 points

Hi,

I've some updates which might help you in helping me. As mentioned I built the project two time once with ti.platform.evmOMAPL138(orginal) and once with ti.platform.evmOMAPL138(in my repository but same memory configuration)

I compared the files with WinMerge leading to several differences in the files (in the following I marked the working in dark green, the code generated due to my own platform definition in dark red. Differences are in Bold, Bright Red, and bigger font size)

..\i2cSample\Debug\i2cSamle.map:

         name            origin    length      used     unused   attr    fill
---------------------- -------- --------- -------- -------- ---- --------
L3_CBA_RAM            80000000   00020000 00000000 00020000 RW X
DDR                   c3000000   01000000 00053757 00fac8a9 RW X
IRAM                  ffff0000   00002000 00000368 00001c98 RW X

         name            origin    length      used     unused   attr    fill
---------------------- -------- --------- -------- -------- ---- --------
L3_CBA_RAM            80000000   00020000 00000000 00020000 RW X
DDR                   c3000000   01000000 00053757 00fac8a9 RWIX
IRAM                  ffff0000   00002000 00000368 00001c98 RW X

..\i2cSample_configuration\Debug\configPfk\linker.cmd:

MEMORY
{
    IRAM (RWX) : org = 0xffff0000, len = 0x2000
    L3_CBA_RAM (RWX) : org = 0x80000000, len = 0x20000
    DDR (RWX) : org = 0xc3000000, len = 0x1000000
}

MEMORY
{
    IRAM (RWX) : org = 0xffff0000, len = 0x2000
    L3_CBA_RAM (RWX) : org = 0x80000000, len = 0x20000
    DDR : org = 0xc3000000, len = 0x1000000
}

..\i2cSample_configuration\Debug\configPfk\package\cfg\i2cSample_xe9.c:

/* --> ti_psp_i2c_I2c_deviceInstInfo__A */
const __T1_ti_psp_i2c_I2c_deviceInstInfo ti_psp_i2c_I2c_deviceInstInfo__A[2] = {
    {
        ((xdc_Ptr)((void*)0x1c22000)), /* baseAddress */
        (xdc_UInt32)0x24, /* cpuEventNumber */
        (xdc_UInt32)0x18, /* rxDmaEventNumber */
        (xdc_UInt32)0x19, /* txDmaEventNumber */
        (xdc_UInt32)0x16e3600, /* inputFrequency */
        (xdc_UInt32)0x0, /* pwrmLpscId */
        (xdc_UInt32)0x0, /* pscInstance */
    }, /* [0] */
    {
        ((xdc_Ptr)((void*)0x1e28000)), /* baseAddress */
        (xdc_UInt32)0x2a, /* cpuEventNumber */
        (xdc_UInt32)0x1a, /* rxDmaEventNumber */
        (xdc_UInt32)0x1b, /* txDmaEventNumber */
        (xdc_UInt32)0x47868c0, /* inputFrequency */
        (xdc_UInt32)0xb, /* pwrmLpscId */
        (xdc_UInt32)0x1, /* pscInstance */
    }, /* [1] */
};

/* --> ti_psp_i2c_I2c_deviceInstInfo__A */
const __T1_ti_psp_i2c_I2c_deviceInstInfo ti_psp_i2c_I2c_deviceInstInfo__A[2] = {
    {
        ((xdc_Ptr)((void*)0x1c22000)), /* baseAddress */
        (xdc_UInt32)0xf, /* cpuEventNumber */
        (xdc_UInt32)0x18, /* rxDmaEventNumber */
        (xdc_UInt32)0x19, /* txDmaEventNumber */
        (xdc_UInt32)0x16e3600, /* inputFrequency */
        (xdc_UInt32)0x0, /* pwrmLpscId */
        (xdc_UInt32)0x0, /* pscInstance */
    }, /* [0] */
    {
        ((xdc_Ptr)((void*)0x1e28000)), /* baseAddress */
        (xdc_UInt32)0x33, /* cpuEventNumber */
        (xdc_UInt32)0x1a, /* rxDmaEventNumber */
        (xdc_UInt32)0x1b, /* txDmaEventNumber */
        (xdc_UInt32)0x47868c0, /* inputFrequency */
        (xdc_UInt32)0xb, /* pwrmLpscId */
        (xdc_UInt32)0x1, /* pscInstance */
    }, /* [1] */
};

plenty of differences in i2cSample_xe9.cfg.xml, i2cSample_xe9.cfg.dot, i2cSample_xe9.dep (too much to post, I could upload them of course if this would help)

excerpt of ..\i2cSample_configuration\Debug\configPfk\package\cfg\i2cSample_xe9.c:

execCmd="@%24%28ECHO%29%20ti.platforms.generic%20cannot%20run%20i2cSample.xe9"

(...)

(...)

<package name="ti.platforms.generic" version="1, 0, 0, 1" repository="C:/Programme/Texas Instruments/xdctools_3_20_08_88/packages/">
<module name="ti.platforms.generic.Platform"

execCmd="@%24%28ECHO%29%20ti.platforms.evmOMAPL138%20platform%20package%20cannot%20execute%20i2cSample.xe9%20on%20Windows%0A@%24%28ECHO%29%20Check%20for%20updates%20to%20this%20package%20at%3A%0A@%24%28ECHO%29%20https%3A//www-a.ti.com/downloads/sds_support/targetcontent/rtsc/index.html%0A%09%3A"

(...)

(...)

(...plenty of ti.catalog.c6000 stuff...)

Well those are pretty many differences which are hiding behind the walls of the RTSC Platform creation wizard. I'm not sure maybe the RWX instead of RWIX already is. Or the CPU event numbers. This all is pretty overwhelming for me...

Thanks
Stefan

0 Raghavendra Maddikery over 14 years ago

TI__Expert 5500 points

Hi Stefan,

I installed all the tools specified in the OMAPL138_BIOSPSP_Userguide.pdf. Then using CCSv4 built the I2C ARM sample application. Following are list of experiments conducted:

1. Built I2C sample application(ARM) using platforms - ti.platforms.evmOMAPL138

Result: Application completed successfully. Here are the log messages:

!!! PSP HrtBt

2. Built I2C sample application(ARM) using platforms - ti.sdo.ipc.examples.platforms.evmOMAPL138.arm

Result: Application completed successfully

!!! PSP HrtBt

To simulate your problem at my place (Since you do not have the slave device - TCA6416), I have conducted few more experiments like,

1. Built I2C sample application(ARM) using platforms - ti.platforms.evmOMAPL138. But in this case, used an invalid Slave address and stream_write(..) time out value set to 50.

Result:

              EDMA driver initialization PASS.
              I2C Sample Application
              I2C :Start of I2C sample application
              Stream_create(outHandle) returned status = 0
              Stream_create(inHandle) returned status = 0
              I2C exapnder/LEDs write/read test started
              ti.sdo.io.Stream: line 420: E_timeout: Timeout
              ti.sdo.io.Stream: line 420: E_timeout: Timeout
              I2C Expander configuration failed : 0!ti.sdo.io.Stream: line 498: assertion failure: A_pendingReclaims: Packets issued but not reclaimed

2. Built I2C sample application(ARM) using platforms - ti.sdo.ipc.examples.platforms.evmOMAPL138.arm. But in this case used an invalid Slave address and stream_write(..) with time out value set to 50.

Result:

In both case, "I2C Expander configuration failed : 0!ti.sdo.io.Stream: line 498: assertion failure: A_pendingReclaims: Packets issued but not reclaimed" can be ignored since the second request has been issued before reclaiming first request.

So I would like you to use all the appropriate tool versions mentioned in the Userguide section 1.1.5, once this setup works then we can move forward to use the tool versions as mentioned by you, if at all required.

Thanks and Regards,

Raghavendra

0 Stefan Koehler over 14 years ago in reply to Raghavendra Maddikery

Intellectual 525 points

Hi Raghavendra,

thanks for your message. I have the tools mentioned in the PSP Userguide installed. The only difference are the verison numbers

EDMA 3 LLD – This package (OMAPL138 BIOS PSP) is compatible with
EDMA 3 LLD versioned 02.10.02.03

I use edma3_lld 02.11.01.02

DSP-BIOS versioned 6.21.03.21

I use BIOS 6.31.04.27

XDC Tools versioned 3.16.03.36

I use xdctools 3.20.08.88

CCS version 4.1.1.00014

I use CCSV 4.2.3.00004

IPC version - ipc_1_20_00_23

I use ipc_1_22_05_27

Code Generation Tools 6.1.12 for building DSP objects

I use Code Generation Tools TI v7.2.0 for DSP

Code Generation Tools 4.6.1 for building ARM objects

I use Code Generation Tools 4.6.4 for ARM

XDS 510 USB Emulator (Optional)

I use XDS100v2 USB Emulator

OMAPL138 EVM CPU Board
OMAPL138 User Interface Module

As mentioned a custom board here

As discussed the strange thing is that the Sample project works for me as described in your second test (with the invalid address) as long as I am using the ti.platforms.evmOMAPL138. But not when using ti.sdo.ipc.examples.platforms.evmOMAPL138.arm. Would you mind to upload your ti.ipc.examples.platforms.evmOMAPL138.arm for me and maybe the debug files which were created using this platform?
What versions of the tools mentioned above are you using for the test?
Is there any possibility that my installation is messed up (the environment variables for the directories are set and the projects build...) and if so, how can i find out?
Don't you think there is a problem with the differences which I found with WinMerge for the different platforms? Would you mind checking your ..\i2cSample\Debug\i2cSamle.map for the "I" in RWIX and ..\i2cSample_configuration\Debug\configPfk\package\cfg\i2cSample_xe9.c for the event numbers?
Is it possible for you to provide me a ti.platform.evmOMAPL138 file (with DSP and GPP entry) with GPP's DDR @ 0xC000 0000 and DSP's DDR @ 0xC100 000

Thanks
Stefan

0 Stefan Koehler over 14 years ago in reply to Stefan Koehler

Intellectual 525 points

A small update: I set bufLen back to 2 and used timeout of 50 instead as you did.

dataBuffer.bufLen    = 2u;
dataBuffer.flags     = I2c_WRITE | I2c_MASTER | I2c_START | I2c_STOP;

/* Send the data on the i2c bus                                           */
size = Stream_write(i2c_outHandle,&dataBuffer,(SizeT)dataBuffer.bufLen,50,eb);

Now i receive the same console messages as you do

EDMA driver initialization PASS.
I2C Sample Application
I2C :Start of I2C sample application
Stream_create(outHandle) returned status = 0
Stream_create(inHandle) returned status = 0
I2C exapnder/LEDs write/read test started
ti.sdo.io.Stream: line 442: E_timeout: Timeout
ti.sdo.io.Stream: line 442: E_timeout: Timeout
I2C Expander configuration failed : 0!ti.sdo.io.Stream: line 520: assertion failure: A_pendingReclaims: Packets issued but not reclaimed
xdc.runtime.Error.raise: terminating execution

Would you mind setting your dataBuffer.bufLen = 1u; and try the test with both, ti.platforms.evmOMAPL138 and ti.sdo.ipc.platforms.evmOMAPL138.arm again?

Thanks
Stefan

0 Raghavendra Maddikery over 14 years ago in reply to Stefan Koehler

TI__Expert 5500 points

Hi Stefan,

I compared the ti.sdo.ipc.platforms.evmOMAPL138.arm and ti.platforms.evmOMAPL138 platforms and observed that the Platform.xdc file differs which can possible raise some issues. Attached is the difference report of both - 2605.Platform_Report.html.

If you observe the structure metaonly module Platform inherits xdc.platform.IPlatform, it has id:"x" which is used by the I2c.xs file(Line: 27 - var i2cs = soc.deviceTable[Program.cpu.deviceName][Program.cpu.id].i2cs) to populate the device info parameters like, cpueventnumber, baseaddress, etc. For ARM, this Id is '1' which populates the device info parameters from the soc.xs file with reference to this id!. But in your case the problem is with the cpueventnumber, Since you are using, ti.sdo.ipc.platforms.evmOMAPL138.arm which comes from the ipc package. In the difference report there is no such id. Hence a default id '0' is taken and due to this the cpueventnumber is populated with value "36" which is inorrect for ARM(refer line:17 of soc.xs file). Whereas, cpueventnumber should be 15 which is appropriate(refer line:602 of soc.xs file) for ARM. Because of this even after the NACK, the CPU is not being interrupted [so NACK will not be handled] and driver raising an error for MST bit not being cleared.

So I did an experiment by changing Program.cpu.id of var i2cs = soc.deviceTable[Program.cpu.deviceName][Program.cpu.id].i2cs (line: 27 of I2c.xs file) to "1" with ti.sdo.ipc.platforms.evmOMAPL138.arm. This change registered the interrupt correctly with appropriate cpueventnumber and worked successfully. This is just a workaround to test our understanding is correct or not. So, If this platform related "id" is corrected, then you are good to go.

So, I request you to create a new thread regarding this platform 'id' in this forum itself and hopefully you will get help from appropriate team who is looking after IPC.

Thanks & regards,

Raghavendra

0 Stefan Koehler over 14 years ago in reply to Raghavendra Maddikery

Intellectual 525 points

Hi Raghavendra,

after manipulating i2c.xs as as you proposed the behaviour of the two platform is equal. The discussion of the platform issue is continued here http://e2e.ti.com/support/embedded/f/355/p/110136/389395.aspx#389395.

I am now receiving the same console output as you are, when using a wrong address.

Raghavendra Maddikery said:

In both case, "I2C Expander configuration failed : 0!ti.sdo.io.Stream: line 498: assertion failure: A_pendingReclaims: Packets issued but not reclaimed" can be ignored since the second request has been issued before reclaiming first request.

It is a possible situation that the I2C Device won't answer. So I get the Timeout. I still want to use the I2C after that, can you tell me how to reclaim the packet or in general what I should do to handle the timeout of a I2C Device? (I didn't find the answer in BIOSPSP_I2C_Driver_Design.pdf). A little code example on this would be great.

I tried the following which stays in Stream_reclaim forever:

size = Stream_write(
                i2c_outHandle,
                &dataBuffer,
                (SizeT)dataBuffer.bufLen,
                50,
                eb);

    if ((TRUE == Error_check(eb)) && (dataBuffer.bufLen != size))
    {
        Stream_abort(i2c_outHandle, NULL);
        Stream_reclaim(i2c_outHandle, (Ptr *)&dataBuffer, BIOS_WAIT_FOREVER, NULL, NULL); //<- stays here forever
        System_printf("I2c Write: Data Write Failed: %d\n",Error_getCode(eb));
    }

in stream.c line 439:

SizeT Stream_reclaim(Stream_Object *obj, Ptr *bufp, UInt timeout, UArg *arg,
Error_Block *eb)

{

(...)

while (obj->ready == 0) {
        if (!Sync_wait(obj->complete, timeout, eb)) {
            if (timeout != 0) {
                Error_raise(eb, Stream_E_timeout, timeout, 0);
            }
            return (0);
        }
    };

(...)

}

obj->ready is not set which is why Sync_wait() waits forever. Should Stream_abort() set the obj->ready?

Raghavendra:

I opened a second new thread since I think the problem here is of other nature then the ones discussed in the previous posts of the current thread. This might help to keep the thread a little more clean. If you disagree feel free to delete the new Thread, otherwise I think it would be best to continue the discussion in the thread: http://e2e.ti.com/support/embedded/f/355/p/110172/389512.aspx#389512

Thanks
Stefan

0 Raghavendra Maddikery over 14 years ago in reply to Stefan Koehler

TI__Expert 5500 points

Hi Stefan,

When you perform the first Stream_write(...) It returns back to the application by updating the error in the error block(eb) and then depending on this, it enters the if{} loop and prints the error message. This error block(eb) is carried forward to the next Stream_write(...). If this eb is not initialized, it will raise an error due to an error being already set/carried from the previous request. So for this, you will have to do a small cahange in the sample application (I2cSample_io.c file) Line:240, you have a Stream_write(...) function. Insert this line - " Error_init(eb); " just before you call this Stream_write(...). This should possibly solve the problem and help you use the I2c even after timeout.

Error_init(eb);

/* Write the data to I2c expander     */
size = Stream_write(
            i2c_outHandle,
            &dataBuffer,
            (SizeT)dataBuffer.bufLen,
            BIOS_WAIT_FOREVER,
            eb);

Try this, and let us know the results.

Thanks & regards,

Raghavendra

0 Stefan Koehler over 14 years ago in reply to Raghavendra Maddikery

Intellectual 525 points

Hi Raghavendra,

did the proposed solution work for you? I didn't modify the given sample but added in i2cExpander_WritePort0(Uint8 *data,Error_Block *eb) and in Void configureExpanderPort(Error_Block *eb) the Error_init(eb) one row above the Stream_write() as you proposed, but the assertion still remains.

So as far as I understand there is a problem of reclaiming the buffer. When I use a timeout in Stream_write() this timeout is forwarded to Stream_reclaim() which means the buffer is not reclaimed when a timeout happens...
Now the IPC_Users_Guide.pdf says the following:

IPC_Users_Guide.pdf: 2.4.9 Stream_abort() and Error Handling said:

(...)

Stream_reclaim() returned an error.

In such cases, the application needs to call Stream_abort() to force the driver
to return all buffers without processing them. After a call to Stream_abort(),
the application still needs to call Stream_reclaim() to get back the buffers.
Stream_reclaim() returns the buffers in the order that they were issued. The
size field returned by Stream_reclaim() is the size processed by the driver.

The cdoc documentation says:

IPC cdoc: details for Stream_abort() said:

The underlying device connected to stream is idled as a result of calling abort and all buffers are ready for reclaim().

The client still needs to call reclaim to get back his buffers. However the client will NOT block when calling reclaim() after an abort().

So as described in my last post I tried the following (now added Error_init)

Error_init(eb);

size = Stream_write(i2c_outHandle,&dataBuffer,(SizeT)dataBuffer.bufLen,50,eb);

if ((TRUE == Error_check(eb)) && (dataBuffer.bufLen != size))
    {
        Stream_abort(i2c_outHandle, eb);
        Stream_reclaim(i2c_outHandle, (Ptr *)&dataBuffer, BIOS_WAIT_FOREVER, NULL, eb);
        System_printf("I2c Write: Data Write Failed: %d\n",Error_getCode(eb));
}

Despite calling Stream_abort Stream_reclaim is not able to reclaim the buffer and stays inside forever. I i comment out the red colored part the buffer is not reclaimed and I receive the mentioned assertion.

It would be great if you could try to reproduce the error to filter out any possible errors I might have done (though I don't believe there are other errors since I didn't modify any of the Sample project but those lines)

Thanks
Stefan

0 Raghavendra Maddikery over 14 years ago in reply to Stefan Koehler

TI__Expert 5500 points

Hi Stefan,

The solution I provided, works for me as expected.

Take the sample application provide by the PSP package and do the following modifications to avoid further confusions.

The only changes I have in my application(i2cSample_io.c) is,

1. An invalid slave address provided.

2. bufLen = 1u.

3. Placing Error_init(eb); only inside the i2cExpander_WritePort0(...) function as suggested above.

And the entire Sample application is built with ti.sdo.ipc.examples.platforms.evmOMAPL138.arm and except for the above changes, there is no other additions/changes in my sample application.

NOTE: In I2c.xs replaced "Program.cpu.id" with 1.

LOG Message as Expected:

EDMA driver initialization PASS.

I2C Sample Application

I2C :Start of I2C sample application

Stream_create(outHandle) returned status = 0

Stream_create(inHandle) returned status = 0

I2C exapnder/LEDs write/read test started

ti.sdo.io.Stream: line 460: E_timeOut: Error in Timeout

I2C Expander configuration failed : 0!ti.sdo.io.Stream: line 460: E_timeOut: Error in Timeout