Interrupt with OMAP-L138

Now i did the following:

I changed CFG_OMAPL138GEM_SHEM.c at #define CODEMEMORYSIZE from 0xFFF80u to 0xA00000u to reserve 10Mbyte for DSP code/data.

The new start address for the ARM part is now at 0xc4900080 ( i get that address when i add all the memory spaces declared in CFG file together started at 0xc3e0000)

Now when i launch uboot with mem=55MB@0xc4900080 (0xc8000000 - 0xc4900080 is equal to 55MB) then the uboot stops loading the kernel. this is the log message:

Starting kernel ...

Uncompressing Linux... done, booting the kernel.

then nothing happens.

Am i doing right with all the address coding?

Please help.Thank you,

regards christian

Christian Willdoner said:

thanks for the hint! I assume i possibly have to modify the DSP Interrupt Vector ID too, as described here? http://processors.wiki.ti.com/index.php/DSPLink_FAQs#DSPLink_sample_applications_and_my_algorithm_work_independently.2C_but_as_soon_as_I_integrate_them.2C_my_DSP_app_stops_receiving_interrupts._Why.3F

You shouldn't need to change DSPLink's vector IDs, unless you really need to use one of those vectors for another purpose, which is unlikely.  FYI, C6x interrupt vectors can handle *any* interrupt source, and most applications don't really care which of the 12 interrupt vectors is used, as long as one of them has been configured to handle the event of interest.

To handle your audio-in interrupt, you would use DSP/BIOS to set up your ISR.  Here's a link to the DSP/BIOS 5.x API guide: http://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=spru403&track=no
The HWI module is documented starting on page 177.

In a nutshell, you need to:
    1 discover which C6x "event" number is associated with the audio-in interrupt source
    2 choose an available, unused HWI vector (you know that vectors 4 & 5 are used by DSPLink, and I believe DSP/BIOS will use 14 for its timer, so choose something else)
    3 call HWI_dispatchPlug() (using the vector chosen in step 2 and your ISR function)
    4 call HWI_eventMap() (to map the event discovered in step 1 to the vector chosen in step 2)
    5 call C64_enableIER(), might be C6x_enableIER() (on the vector chosen in step 2)

If the above is done in main() then the interrupt won't be taken until main() is done (since interrupts are still disabled globally).

The above can mostly also be done with static config in your .tcf file (except for the C64_enableIER())

Christian Willdoner said:

my uboot config says:

setenv bootargs console=ttyUSB0,115200n8 noinitrd rw mem=32M@0xc0000000 mem=64M@0xc4000000 root=/dev/nfs nfsroot=10.78.1.143:/home/chris/targetfs,nolock ip=dhcp

I have two mem arguments, i think i must adjust the mem=64M@0xc4000000 to mem=62M@0xc2000000  to increase the memory size for my DSP code/data?

No, mem=32M@0xc0000000 mem=64M@0xc4000000 causes linux to use memory ranges 0xc0000000 -> 0xc2000000 (that's 32M) and 0xc4000000 -> 0xc8000000 (that's 64M).  This means that the DSP executable has the 32MB range 0xc2000000 -> 0xc4000000 available for it.

The DSPLink samples use the memory map as reflected in CFG_OMAPL138GEM_SHMEM.c.  That memory map ends up being 0xc3e00000 -> 0xc4000000, which should fit nicely in the hole created by your bootargs "mem=" parameters.  That still leaves the memory 0xc2000000 -> 0xc3e00000 unused by either linux or the DSPLink application (sample).

So, using the default DSPLink samples, and your existing "mem=" settings, the samples should be running.  In your initial post you mentioned something about initializing RAM:
    this happens when the program initializes the RAM on EMIFB (external memory interface B)
Can you expand on that statement?  Who is initializing what?

Regards,

- Rob

Christian Willdoner said:

Now when i launch uboot with mem=55MB@0xc4900080 (0xc8000000 - 0xc4900080 is equal to 55MB) then the uboot stops loading the kernel. this is the log message:

Starting kernel ...

Uncompressing Linux... done, booting the kernel.

then nothing happens.

Am i doing right with all the address coding?

I suspect that the boot hangs because you've given linux some non-existant memory.  0xc4900080 + 55M = 0xc8000080.

Also, I don't know that it's bad, but you should probably start your linux memory on a large alignment boundary, such as 0xc4900000 (not 0xc4900080).  Perhaps you should use 10MB - 80 for your DSP code/data size.

FYI, you typed 55MB@0xc4900080 but it should not have "MB", just "M".  It's probably correct on your actual command and you mistyped above, but I just want to make sure.

Regards,

- Rob

Robert Tivy said:

In your initial post you mentioned something about initializing RAM:
    this happens when the program initializes the RAM on EMIFB (external memory interface B)
Can you expand on that statement?  Who is initializing what?

Thats right, this happens in the evmomapl138.c (this file is included in the GEL_BSL zip board support library package downloaded from logicpd site for the OMAP-L138).

Code snippet:

//-----------------------------------------------------------------------------
// \brief   initializes ram on EMIFB.
//
// \param   none.
//
// \return  uint32_t
//    ERR_NO_ERROR - everything is ok...ram ready to use.
//    ERR_INIT_FAIL - something happened during initialization.
//-----------------------------------------------------------------------------
uint32_t EVMOMAPL138_initRAM(void)
{
   uint32_t rtn = 0;
   
   // unlock the system config registers and set the ddr 2x clock source.
   SYSCONFIG->KICKR[0] = KICK0R_UNLOCK;
   SYSCONFIG->KICKR[1] = KICK1R_UNLOCK;
   CLRBIT(SYSCONFIG->CFGCHIP[3], CLK2XSRC);

....

When the program enters    CLRBIT(SYSCONFIG->CFGCHIP[3], CLK2XSRC); the program gets to HWI_NWI and after resuming it hangs in HWI_RESET in this messagecfg.s62 File. I have really no idea what this means..

Other question.

I am trying to merge the DSPLink Message Example with the audio example from biospsp. I get several undefined symbol errors when trying to compile it.

I know the c674x_5.xx_linux.mk file, i included some more base directories for include files, but now i stuck with the including of libraries for the bios. Where do i have to do that and how? some guidance will be appreciated.

dsplink version 1.65.01.05

biospsp version 1.30.01

edma3lld version 01.11.02.05

Christian Willdoner said:

I know the c674x_5.xx_linux.mk file, i included some more base directories for include files, but now i stuck with the including of libraries for the bios

Christian,

I'm not sure if this is the "canonical" way for DSPLink, but I believe you can edit the file:
    <dsplink>/dsp/src/samples/message/DspBios/COMPONENT
and add to the USR_LIBS macro, somewhere after its initial definition, e.g.:
    USR_LIBS        := dsplink.lib
    USR_LIBS        += <your.lib>

Regards,

- Rob

Christian Willdoner said:

//-----------------------------------------------------------------------------
// \brief   initializes ram on EMIFB.
//
// \param   none.
//
// \return  uint32_t
//    ERR_NO_ERROR - everything is ok...ram ready to use.
//    ERR_INIT_FAIL - something happened during initialization.
//-----------------------------------------------------------------------------
uint32_t EVMOMAPL138_initRAM(void)
{
   uint32_t rtn = 0;
   
   // unlock the system config registers and set the ddr 2x clock source.
   SYSCONFIG->KICKR[0] = KICK0R_UNLOCK;
   SYSCONFIG->KICKR[1] = KICK1R_UNLOCK;
   CLRBIT(SYSCONFIG->CFGCHIP[3], CLK2XSRC);

....

When the program enters    CLRBIT(SYSCONFIG->CFGCHIP[3], CLK2XSRC); the program gets to HWI_NWI and after resuming it hangs in HWI_RESET in this messagecfg.s62 File. I have really no idea what this means..

Christian,

A DSP program reaches the HWI_NMI vector when something "bad" has happened.  The HWI_NMI is invoked when a C674x Exception is hit, and apparently it is a result of running the above function, which makes sense since it's doing some low-level system stuff.

I don't think you want to call that function, really.  In a Linux environment the Linux kernel typically initializes EMIFs, and when a user wants to run some DSP program without Linux running on the ARM then they will typically use CCS to attach to the DSP followed by running some GEL initialization script functions to initialize EMIFs, followed by loading/running the DSP program.

I'm not a HW expert by any means, but FYI, the KICK registers are not utilized in OMAPL138 Rev 2 & higher chips (they're not needed to access SYSCFG registers).  I'm not sure if that means that writes to them will fault, though.  I realize you're just running prepackaged stuff from the BSL and probably don't know about this stuff, but I thought I'd throw that out there.

Anyways, when an exception does happen, DSP/BIOS itself typically will print useful exception information in its NMI handler.  There's a nice tool named KOV that could conceivably be used to view DSP/BIOS logs (or perhaps you have LOG prints configured to go to stdout, which is the CCS "console" window).  However, I'm not sure it would even help to see the particular exception information, since it will most likely just point to the fact that you shouldn't be doing what you're doing.

Hope this helps...

Regards,

- Rob

Thank you for your support!

I heed your advice on the interrupt thing and leave it at that.

The only thing i want to do is to sample a signal (e.g. a sinus at 1Khz) via Line-In on the Board, to fouriertransform it and to print the resulting frequency with ARM on a terminal window e.g. on a PC.

Now I try following completeley different:

I merge the biospsp example "audio" with the "audio soc example" from DVSDK package. The audio soc is my main project and i copy the SIO streaming part from the audio example into it.

I managed to merge it without any compile errors but it is not working.The program hangs when the ARM says "DSP message located" if you know. In the outputThread.c i added lines for creating an Inputstream, by using the correct memory allocation functions and parameters. This works without errors. Then, in the original outputThread.c there is a SIO_issue(outputstream,....). As soon as i add a SIO_issue(inputstream, ....) the program hangs.

Is there a problem by issuing two streams?

Christian Willdoner said:

Then, in the original outputThread.c there is a SIO_issue(outputstream,....). As soon as i add a SIO_issue(inputstream, ....) the program hangs.

Is there a problem by issuing two streams?

No, there should not be any problem using two SIO streams simultaneously, that is done frequently in DSP/BIOS applications.

The SIO_issue() API should not be blocking, so I assume that the hang you report is a crash.

Can you hook up CCS and determine where the DSP is stuck?

Feel free to attach your C source code and DSP/BIOS configuration (typically in a file with a .tcf extension).

I'm not familiar with the biospsp or DVSDK, so I may have to pass you off to someone else.

Regards,

- Rob

Ok, the only .tcf file i found was audio.tcf in the dsp directory from the audio soc example. i have attached it.

I also attached the main.c from the dsp and the outputThread.c, the other files from the audio soc example i hardly modified.

3755.audio-soc-example_modified_files.tar.gz

Debugging with the CCS is a bit problematic, after the cursor is on

if (TSK_create((Fxn)ThreadInit, &attrs) == NULL) {
        SYS_abort("Failed create echo thread");
}

in the main.c i want to step into the TSK_create function to get into the outputThread.c file but i could not manage it so far to do so. I have set a breakpoint in the outputThread.c but this does not change anything.

best regards,

christian

additionally to the audio soc example i found out:

In the audioDriver.tci file i added a new instance of DIO object dioAudioIN, in addition to the existing dioAudioOUT. But this does not change anything, the program still stucks when i call SIO_issue(inputStream,...). Then I discovered the file audio.cdb and added a new object dioAudioIN, also this does not change anything. Then there is a file called audiocfg.s62 which should not be modified by the user. But there is also an entry with dioAudioOUT, so i added the same for dioAudioIN. But nothing changes, still stucks.

I believe this is a failure where some audio In streaming is not defined, because the audio soc example is made for audio Out streaming, but there must be a way to adapt it for audio in streaming..

Christian Willdoner said:

Debugging with the CCS is a bit problematic, after the cursor is on

if (TSK_create((Fxn)ThreadInit, &attrs) == NULL) {
        SYS_abort("Failed create echo thread");
}

in the main.c i want to step into the TSK_create function to get into the outputThread.c file but i could not manage it so far to do so. I have set a breakpoint in the outputThread.c but this does not change anything.

When calling TSK_create() from main(), the scheduler is not active.  TSKs will start to execute after main() returns.  I'm not sure what's causing your BPs to not get hit, do you have indication otherwise that that code w/ the BP is actually getting executed?

As to your, er, issue with SIO_issue(inputStream, ...), I observed that you're not actually allocating memory and assigning those pointers to the buf2[] array (which you use for the SIO_issue()), and I would expect that to cause a hang on the DSP when SIO tries to access a NULL pointer (or perhaps some junk value since DSP global data doesn't get automatically zero-initialized).  Please try correcting that.

Regards,

- Rob

I see, i have sent you a wrong file. I corrected the thing with the buf2[] and allocated it. I also managed to debug into the source of outputThread and now i stuck in the SIO_create(inputstream) in the createStreams() method, i get NULL as return value. I think the stacksize is for the Task is to less for creating two streams?

If i am assuming right ,can you tell me which stacksize is the right one to adjust?

In the audio.tcf there is bios.MEM.STACKSIZE = 0x10000;

In the app.tci there is bios.TSK.STACKSIZE = 0x200;

In the main.c is:

   // Create initialization thread to finalize driver initialization
    attrs.name = "ThreadInit";
    attrs.stacksize = 0x1000;
    if (TSK_create((Fxn)ThreadInit, &attrs) == NULL) {
        SYS_abort("Failed create echo thread");
    }

and in the ThreadInit Method in main.c is set

    attrs.name = "output";
    attrs.stacksize = 0x1000;
    if (TSK_create((Fxn)outputThread, &attrs) == NULL) {
        SYS_abort("Failed create output thread");
    }

thank you.

Christian Willdoner said:

I also managed to debug into the source of outputThread and now i stuck in the SIO_create(inputstream) in the createStreams() method, i get NULL as return value. I think the stacksize is for the Task is to less for creating two streams?

I would doubt that the stacksize is too small.  For one thing, 0x1000 should be enough.  And creating two streams would use no more stack than creating just one stream.  When a TSK stack is too small you won't typically get a nice clean failure from some API, but instead the stack will overrun and result in corrupting some adjacent data object (such as the TSK object itself).

There are many reasons that SIO_create() can return NULL.  The most common ones would be:
    - not enough heap for the SIO object plus 2 QUE objects plus a DEV frame
    - invalid name of device, resulting in a failure of the DEV_match() function called by SIO_create().
When SIO_create() returns NULL, there will be an associated error message in DSP/BIOS's SYS output buffer.  You can use CCS to display the SYS output buffer, using the KOV tool from inside of CCS.  We would need to see this output print to determine further the cause of the SIO_create() failure.  Please try to make sure that the name you're using for SIO_create() is indeed a DEV that is present in the program's configuration.

FYI, bios.MEM.STACKSIZE is the "system" stack size used for processing HWI & SWI threads, and 0x10000 is plenty big.  bios.TSK.STACKSIZE is the default TSK stack size when not otherwise specified in the TSK_Attrs.  And finally, the attrs.stacksize is the stack size used for the TSK that you are creating with TSK_create(), and takes precendence over bios.TSK.STACKSIZE.

Regards,

- Rob

Thanks for the clarification about stacksizes.

How do i open the KOV tool? I use CCS v5.3, all i can find is the ROV remote operated vehicle.

This is my programs configuration:

/* Add I2c driver to DEV table */
bios.UDEV.create("i2c0");
bios.UDEV.instance("i2c0").fxnTableType = "IOM_Fxns";
bios.UDEV.instance("i2c0").initFxn = prog.extern("audioUserI2cInit");
bios.UDEV.instance("i2c0").params = prog.extern("audioI2cParams");
bios.UDEV.instance("i2c0").fxnTable = prog.extern("I2c_IOMFXNS");
bios.UDEV.instance("i2c0").deviceId = 0;


/* Add Aic31 driver to DEV table */
bios.UDEV.create("aic310");
bios.UDEV.instance("aic310").fxnTableType = "IOM_Fxns";
bios.UDEV.instance("aic310").initFxn = prog.extern("audioUserAic31Init");
bios.UDEV.instance("aic310").params = prog.extern("audioAic31Params");
bios.UDEV.instance("aic310").fxnTable = prog.extern("Aic31_IOMFXNS");
bios.UDEV.instance("aic310").deviceId = 0;

/* Add Mcasp driver to DEV table */
bios.UDEV.create("mcasp0");
bios.UDEV.instance("mcasp0").fxnTableType = "IOM_Fxns";
bios.UDEV.instance("mcasp0").initFxn = prog.extern("audioUserMcaspInit");
bios.UDEV.instance("mcasp0").params = prog.extern("audioMcaspParams");
bios.UDEV.instance("mcasp0").fxnTable = prog.extern("Mcasp_IOMFXNS");
bios.UDEV.instance("mcasp0").deviceId = 0;

/* Add Audio driver to DEV table */
bios.UDEV.create("audio0");
bios.UDEV.instance("audio0").fxnTableType = "IOM_Fxns";
bios.UDEV.instance("audio0").initFxn = prog.extern("audioUserAudioInit");
bios.UDEV.instance("audio0").params = prog.extern("audioParams");
bios.UDEV.instance("audio0").fxnTable = prog.extern("Audio_IOMFXNS");

/*
 *  Add instance of DIO object to use the configured codec. This is the device
 *  SIO streams use.
 */
var dioCodec = bios.DIO.create("dioAudioIN");
dioCodec.deviceName = prog.get("audio0");
dioCodec.useCallBackFxn = false;
dioCodec.chanParams = prog.extern("audioChanParamsIN");

var dioCodec = bios.DIO.create("dioAudioOUT");
dioCodec.deviceName = prog.get("audio0");
dioCodec.useCallBackFxn = false;
dioCodec.chanParams = prog.extern("audioChanParamsOUT");

And this is my Definition of the channel parameters:

Mcasp_HwSetupData mcaspRcvSetup = {
        /* .rmask    = */ 0xFFFFFFFF, /* All the data bits are to be used     */
        /* .rfmt     = */ 0x00008070, /*
                                       * 0 bit delay from framsync
                                       * MSB first
                                       * No extra bit padding
                                       * Padding bit (ignore)
                                       * slot Size is 16
                                       * Reads from DMA port
                                       * NO rotation
                                       */
        /* .afsrctl  = */ 0x00000000, /* burst mode,
                                       * Frame sync is one bit
                                       * Rising edge is start of frame
                                       * externally generated frame sync
                                       */
        /* .rtdm     = */ 0x00000001, /* slot 1 is active (DSP)               */
        /* .rintctl  = */ 0x00000003, /* sync error and overrun error         */
        /* .rstat    = */ 0x000001FF, /* reset any existing status bits       */
        /* .revtctl  = */ 0x00000000, /* DMA request is enabled or disabled   */
        {
             /* .aclkrctl  = */ 0x00000000,
             /* .ahclkrctl = */ 0x00000000,
             /* .rclkchk   = */ 0x00000000
        }
} ;

Mcasp_HwSetupData mcaspXmtSetup = {
        /* .xmask    = */ 0xFFFFFFFF, /* All the data bits are to be used     */
        /* .xfmt     = */ 0x00008070, /*
                                       * 0 bit delay from framsync
                                       * MSB first
                                       * No extra bit padding
                                       * Padding bit (ignore)
                                       * slot Size is 16
                                       * Reads from DMA port
                                       * NO rotation
                                       */
        /* .afsxctl  = */ 0x00000000, /* burst mode,
                                       * Frame sync is one bit
                                       * Rising edge is start of frame
                                       * externally generated frame sync
                                       */
        /* .xtdm     = */ 0x00000001, /* slot 1 is active (DSP)               */
        /* .xintctl  = */ 0x00000007, /* sync error,overrun error,clK error   */
        /* .xstat    = */ 0x000001FF, /* reset any existing status bits       */
        /* .xevtctl  = */ 0x00000000, /* DMA request is enabled or disabled   */
        {
             /* .aclkxctl  = */ 0x00000000,
             /* .ahclkxctl = */ 0x00000000,
             /* .xclkchk   = */ 0x00000000
        },

};


/* McBsp channel parameters                                  */
Mcasp_ChanParams  mcasp_chanparam[Audio_NUM_CHANS]=
{
    {
        0x0001,                    /* number of serialisers      */
        {Mcasp_SerializerNum_12, }, /* serialiser index           */
        &mcaspRcvSetup,
        TRUE,
        Mcasp_OpMode_TDM,          /* Mode (TDM/DIT)             */
        Mcasp_WordLength_16,
        NULL,
        0,
        NULL,
        NULL,
        1,                        /* number of TDM channels      */
        Mcasp_BufferFormat_1SER_1SLOT,
        TRUE,
        TRUE
    },
    {
        0x0001,                   /* number of serialisers       */
        {Mcasp_SerializerNum_11,},
        &mcaspXmtSetup,
        TRUE,
        Mcasp_OpMode_TDM,
        Mcasp_WordLength_16,      /* word width                  */
        NULL,
        0,
        NULL,
        NULL,
        1,                        /* number of TDM channels      */
        Mcasp_BufferFormat_1SER_1SLOT,
        TRUE,
        TRUE
    }
};

Audio_ChannelConfig audioChanParamsIN =
{
    /*  channel 0 (RX)                         */
    (Ptr)&mcasp_chanparam[0],
    {   /* codec [0]                           */
        {
            44100,  /* sampling rate for codec */
               30,  /* gain (%) for codec      */
             0x00,
             0x00
        }
    }
};

Audio_ChannelConfig audioChanParamsOUT =
{        
    /*  channel 1 (TX)                         */
    (Ptr)&mcasp_chanparam[1],      
    {
        /* codec [1]                           */
        {
            44100,  /* sampling rate           */
               70,  /* gain (%) for codec      */
             0x00,
             0x00
        }
    }
};

I increased the heap size and now the program runs through without errors, the ROV tools helped, thank you very much!

regards christian