This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

error creating SIO stream

Other Parts Discussed in Thread: OMAP-L138, OMAPL138

I'am using the McBSP, EDMA and SIO data stream. This works. Now I want to create a new stream but get a error message SYS_error called: error id = 0x3
I'am using the LogicPD evm board with a OMAP L138 DSP/Bios.

For testing I have build a test project with only the SIO stream in there for error tracking. Below is the code for this.
I'am getting the error: SYS_error called: error id = 0x3

What is wrong??

 

 

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <dio.h>
#include <sio.h>

#include "Bioscfg.h"  //BIOS include file

 

 

 

 

 

void Writer_Thread();
void Reader_Thread();
void testStream();


SIO_Handle mcbspOutHandle;
SIO_Attrs sioAttrs;

int main ()
{
 testStream();
 
 return 0;
}

void testStream()
 {
  mcbspOutHandle = NULL;
   sioAttrs  = SIO_ATTRS;  
   sioAttrs.nbufs = 1;
   sioAttrs.align = 128;
   sioAttrs.model = SIO_ISSUERECLAIM;
 
   /* Create a TX channel for the transmission                               */
   mcbspOutHandle = SIO_create("/dioMcbspOUT", SIO_INPUT, 10, &sioAttrs);
     if (NULL == mcbspOutHandle)
     {
       LOG_printf(&LOG_MBX,"Stream Creation Failed");
     }
     else {
       LOG_printf(&LOG_MBX,"Stream Creation OK");
     }
 } 

  • Royke,

    It appears that you are getting an error (SYS_ENODEV) because there is no device called "/dioMcbspOUT" in the device table, so the match-up failed.

     

    Also, what version of BIOS are you using?

  • Hi David,

    First, thanks for responding.
    I am using DSP/BIOS 5.41.09.34

    Before calling the SIO_create I create a device without getting a error.

      // Create DIO adapter
      if (DEV_createDevice("/dioMcbspOUT", &DIO_tskDynamicFxns, (Fxn)DIO_init, &pAdcForceIf->dioAttrs) != SYS_OK) {
        SYS_abort("Unable to create McBsp1 DIO adapter");
        return -1;
      }

    So the device is there.

  • Some more information. I was already using McBSP0 with a ADC connected to that. It works ok (Only as input, 4 sio streams). Now I am trying to use also the McBSP1.
    If I disable the McBsp0 (by remarking the code) the McBsp1 seems to work ok. But when I use both I get a error creating the SIO stream.

    So what am I doing wrong?

    See code below in zipfile below

     

  • Is there nobody at TI who can help me? maybe Randy?

     

  • Royke,

    We are very sorry that no answer has come out. The holidays hit, but Eric has been trying to get an answer for you.

    My first thought was that you had a typo in your device name strings, but they look right. I was confused a bit by the differences from one post to the next, but within the big code listing post the names match.

    Just taking a guess at something to try, I will recommend that you shorten the names to /DioMB0 and /DioMB1 just to see if there is a field-length limitation. Meanwhile, we can hope that someone who really knows the drivers might see something you and I have missed.

    Regards,
    RandyP

  • Hi Randy,

     

    Thank you for responding. I have change the names without any luck.
    Like I said before, If I disable (not use) McBsp1 than the McBsp0 works fine.
    I have made (and added) a Test project with only the requered parts for using the McBsp's.

    If I disable ADC1_Init(); in the function main in Main.cpp, the McBsp0 works fine.
    But If  I enable it, the McBsp0 stream creation fails.

    I order to run the project you have to have the following system variables:

    EDMA3LLD_BIOS5_INSTALLDIR C:\OMAP-L138_dsp_1_00_00_11\REL_EDMA3_LLD_BIOS5_01_11_00_03
    LOGICPD_OMAPL138_BSL C:\LogicPD\omapl138\bsl
    PSP_DRIVERS_INSTALL_DIR  C:\OMAP-L138_dsp_1_00_00_11\pspdrivers_01_30_01
     

    1050.20110105[11.35]_Testing McBsp0 and 1.zip

  • Hi Royke,

    I just wanted to give you an update so you know what's going on.

    This problem was just brought to my attention today and I am currently looking into it. I have not determined the root cause yet, but will continue on it next week and get back to you as soon as I have some more information.

    Have a great weekend,

    Steve

  • Royke,

    I just wanted to give you an update...

    I'm able to reproduce the problem here, although slightly different.  I see error code 6 instead of 3:

    SYS_error called: error id = 0x6

    I'll continue looking into this tomorrow, and hopefully I'll have some more insight on the failure.

    Thanks,

    Steve

  • Thanks Steve,

    With this code like I get also SYS_error called: error id = 0x6 instead of 3. So you have the same situation now. I hope you can find the problem.

     

     

  • Royke,

    We've found the problem here, it is a bug in the PSP drivers.  The problem was due to the Mcbsp_init() function being called twice; this init function zeros out the Mcbsp_Instances[devId] array which is OK the first time, but when it's called the second time (for mcbsp1), it deletes all the initialization for mcbsp0.

    Although this function is called by your application 2 times (first in adc0.cpp fxn mcbspUserInit(), then again in adc1.cpp fxn mcbspUserInit()), this is NOT a user error, it is a bug in the driver because the driver function Mcbsp_init() should handle the case of the user calling it more than one time.

    The good news is there is a workaround.  Please see the attached updated project.  Note that it's a zip file, but I've renamed it to the extension ".tmp" since we can't attach zip files.  Please rename it and extract.

    I've made changes to the files Main.cpp, adc0.cpp and adc1.cpp so that the Mcbsp_init() code is only called one time.  You should be able to diff these files against the ones you have to see the changes.

    I'll file a bug against the PSP drivers for this issue, too, then update the forum with the bug number.

    Please let me know what happens when you try this workaround!

    Steve

  • Here's the bug for this:

    SDOCM00078075  Mcbsp_init function should protect against multiple calls

    Also, I've attached the file.  Looks like the zip file works after all.

    Steve1513.updated_testing_mcbsp0and1.zip

  • Hi Steven,

     

    First of all, many thanks!! The McBsp1 runs also in my complete project with this workaround . Now I can setup the McBsp1 to communicate with the 24bits ADC.
    When you see the problem you think that is obvious to call not twice the Mcbsp_init(), but I must say, that it was not easy to figure out how to configure McBsp0 AND McBsp1.
    I could't find much about this, so I had to reason logically this out.

    Steven, I also have a post on this forum (http://e2e.ti.com/support/embedded/f/355/p/70809/256749.aspx#256749) about using the EDMA to sort the data from the McBsp to the memory . 
    you responded to the question to get this thread moved to the PSP Drivers - EDMA forums. The EDMA team should know more about this issue as well as how to solve it. 
    But I never heard from them! Can you push it again? This testproject can also be used for this.

     

  • Hi Steven,

    The McBsp1 is not working like I hoped. There is no signal on CLKR1, should have be a clock of 1MHz like the McBsp0. Also there is no signal on FSR1. (must be 10KHz like on the McBsp0).
    I have checked and checked and don't see what is wrong. Changed the pin MUX a bit but no success.

     

      sysCfgRegs = (CSL_SyscfgRegsOvly)CSL_SYSCFG_0_REGS;   

      sysCfgRegs->PINMUX1 &=  ~(CSL_SYSCFG_PINMUX1_PINMUX1_7_4_MASK   | /* CLKR1 */
    //    CSL_SYSCFG_PINMUX1_PINMUX1_11_8_MASK  |
    CSL_SYSCFG_PINMUX1_PINMUX1_15_12_MASK | /* FSR1 */
    //    CSL_SYSCFG_PINMUX1_PINMUX1_19_16_MASK |
       CSL_SYSCFG_PINMUX1_PINMUX1_23_20_MASK | /* DR1 */
       CSL_SYSCFG_PINMUX1_PINMUX1_27_24_MASK | /* DX1 */
       CSL_SYSCFG_PINMUX1_PINMUX1_31_28_MASK);

      sysCfgRegs->PINMUX1 = 0x02202020;// see pinmuxtool

    added: I have played with it and if I enable the McBsp1 in the testproject, then there is also none FSR0 clock signal. When I disable yhe McBsp1 the FSR0 clock is back again.
    So I thing the suggested solution is not fully solving my problem. 

    Can you help me?

     

  • Hi Royke,

    Since you are using the both instance of the McBSP (0 and 1), you need to enable the Pinmux accordingly. I have checked your attachment for pin mux settings, for McBSP-0, it looks fine.

    But McBSP instance 1, there needs to be some changes made. The PINMUX1_31_28 should be made as 02h, to enable the CLKS1, even though no external clock source is being used.

    By default the BIOS PSP package 1_30_01 comes with the McBSP configured for instance 1, so if you refer to the file “mcbsp_evmInit.c” file in the folder “\pspdrivers_01_30_01\packages\ti\pspiom\platforms\evm6748\src “, the PINMUX configuration for McBSP – instance 1 can be found. Please follow the same.

    Thanks and Regards,

    Sandeep K

  • Hi Sandeep,

     

    Thanks for responding, I had the same pinmux like in mcbsp_evmInit.c and tried it again, but having the same problem.

  • Hi Royke,

    I have some of the questions/suggestions as mention in the list,

        1. Basically the BIOS PSP comes with an example for McBSP which uses the instance 1. Have you tried this example, if yes, is it working file?

        2. Could you please send me the snap shot of McBSP(instance 1 and instance 0) register?

        3. Have you ever tried using instance - 0/1 individually? If not, then try only ADC1_Init() by commenting the ADC0_Init() and see whether the clocks are coming or not?

        4.  I suppose, you are opening the McBSP only in INPUT mode, am I right?

     Thanks and Regards,

    Sandeep K

  • Hi Sandeep,

    Here are my answer to your questions.

    1. Yes I tried the demo apps and they seem to work ok.

    2. 

    McBSP0DSP

    DRR = 0x00000000

    DXR = 0x00000000

    SPCR = 0x02000000

    _RSV = 0x0

    FREE = ENABLE (0x1)

    SOFT = DISABLE (0x0)

    FRST = RESET (0x0)

    GRST = RESET (0x0)

    XINTM = XRDY (0x0)

    XSYNCERR = NO (0x0)

    XEMPTY = YES (0x0)

    XRDY = NO (0x0)

    XRST = DISABLE (0x0)

    DLB = DISABLE (0x0)

    RJUST = RZF (0x0)

    CLKSTP = DISABLE_00 (0x0)

    _RSVD = ***

    DXENA = OFF (0x0)

    Reserved = *

    RINTM = RRDY (0x0)

    RSYNCERR = NO (0x0)

    RFULL = NO (0x0)

    RRDY = NO (0x0)

    RRST = DISABLE (0x0)

    RCR = 0x00020540

    RPHASE = SINGLE_FRM (0x0)

    RFRLEN2 = 0x0

    RWDLEN2 = 8BIT (0x0)

    RCOMPAND = MSB (0x0)

    RFIG = YES (0x0)

    RDATDLY = 2BIT (0x2)

    _RSVD = *

    RFRLEN1 = 0x5

    RWDLEN1 = 16BIT (0x2)

    RWDREVRS = DISABLED (0x0)

    _RSVD = ****

    XCR = 0x00000000

    SRGR = 0x205F019B

    GSYNC = FREE (0x0)

    CLKSP = RISING (0x0)

    CLKSM = INTERNAL (0x1)

    FSGM = DXR2XSR (0x0)

    FPER = 0x5f

    FWID = 0x1

    CLKGDV = 0x9b

    MCR = 0x00000000

    RCERE0 = 0x00000000

    XCERE0 = 0x00000000

    PCR = 0x00000500

    FSXM = EXTERNAL (0x0)

    FSRM = INTERNAL (0x1)

    CLKXM = INPUT (0x0)

    CLKRM = OUTPUT (0x1)

    SCLKME = NO (0x0)

    FSXP = ACTIVEHIGH (0x0)

    FSRP = ACTIVEHIGH (0x0)

    CLKXP = RISING (0x0)

    CLKRP = FALLING (0x0)

    RCERE1 = 0x00000000

    XCERE1 = 0x00000000

    RCERE2 = 0x00000000

    XCERE2 = 0x00000000

    RCERE3 = 0x00000000

    XCERE3 = 0x00000000

     

    McBSP1DSP

    DRR = 0xFFFFFFFF

    DXR = 0xFFFFFFFF

    SPCR = 0x02C00037

    _RSV = 0x0

    FREE = ENABLE (0x1)

    SOFT = DISABLE (0x0)

    FRST = FSG (0x1)

    GRST = CLKG (0x1)

    XINTM = XRDY (0x0)

    XSYNCERR = NO (0x0)

    XEMPTY = YES (0x0)

    XRDY = NO (0x0)

    XRST = DISABLE (0x0)

    DLB = DISABLE (0x0)

    RJUST = RZF (0x0)

    CLKSTP = DISABLE_00 (0x0)

    _RSVD = ***

    DXENA = OFF (0x0)

    Reserved = *

    RINTM = RSYNCERR (0x3)

    RSYNCERR = NO (0x0)

    RFULL = YES (0x1)

    RRDY = YES (0x1)

    RRST = ENABLE (0x1)

    RCR = 0x000207A0

    RPHASE = SINGLE_FRM (0x0)

    RFRLEN2 = 0x0

    RWDLEN2 = 8BIT (0x0)

    RCOMPAND = MSB (0x0)

    RFIG = YES (0x0)

    RDATDLY = 2BIT (0x2)

    _RSVD = *

    RFRLEN1 = 0x7

    RWDLEN1 = 32BIT (0x5)

    RWDREVRS = DISABLED (0x0)

    _RSVD = ****

    XCR = 0x00010000

    XPHASE = SINGLE_FRM (0x0)

    XFRLEN2 = 0x0

    XWDLEN2 = 8BIT (0x0)

    XCOMPAND = MSB (0x0)

    XFIG = YES (0x0)

    XDATDLY = 1BIT (0x1)

    _RSVD = *

    XFXLEN1 = 0x0

    XWDLEN1 = 8BIT (0x0)

    XWDREVRS = DISABLED (0x0)

    _RSVD = ****

    SRGR = 0x30FF0139

    GSYNC = FREE (0x0)

    CLKSP = RISING (0x0)

    CLKSM = INTERNAL (0x1)

    FSGM = FSG (0x1)

    FPER = 0xff

    FWID = 0x1

    CLKGDV = 0x39

    MCR = 0x00000000

    RCERE0 = 0x00000000

    XCERE0 = 0x00000000

    PCR = 0x00000500

    FSXM = EXTERNAL (0x0)

    FSRM = INTERNAL (0x1)

    CLKXM = INPUT (0x0)

    CLKRM = OUTPUT (0x1)

    SCLKME = NO (0x0)

    FSXP = ACTIVEHIGH (0x0)

    FSRP = ACTIVEHIGH (0x0)

    CLKXP = RISING (0x0)

    CLKRP = FALLING (0x0)

    RCERE1 = 0x00000000

    XCERE1 = 0x00000000

    RCERE2 = 0x00000000

    XCERE2 = 0x00000000

    RCERE3 = 0x00000000

    XCERE3 = 0x00000000

     

    3. Yes, If I remark ADC1_init(), McBsp0 is working like I set it up. If I enable ADC1_init() only the CLKR0 clock comes out and no FSR0 clock.

    When I disable McBsp0, McBsp1 still not works. 

     4.  Yes, I'am  opening the McBSP only in INPUT mode.

  • Hi Royke,

    Could you please share the sample application which you have used to get the McBSP register snap shot? 

    Thanks and Regards,

    Sandeep K

  • I'am using the test app that I posted in this threat with the workaround from Steven.
    My feeling is that the McBsp1 register is not/or not goed set.
    If I run the test app after a fresh start the McBsp1 registers are not set

    McBSP1DSP
    DRR = 0x00000000
    DXR = 0x00000000
    SPCR = 0x02000000
    RCR = 0x00000000
    XCR = 0x00000000
    SRGR = 0x20000001
    MCR = 0x00000000
    RCERE0 = 0x00000000
    XCERE0 = 0x00000000
    PCR = 0x00000000
    RCERE1 = 0x00000000
    XCERE1 = 0x00000000
    RCERE2 = 0x00000000
    XCERE2 = 0x00000000
    RCERE3 = 0x00000000
    XCERE3 = 0x00000000

     But if I run my app (McBsp part is the same) the McBsp1 regs look like:

    McBSP1DSP
    DRR = 0xFFFFFFFF
    DXR = 0x00000000
    SPCR = 0x02C00037
    RCR = 0x000207A0
    XCR = 0x00000000
    SRGR = 0x20FF0139
    MCR = 0x00000000
    RCERE0 = 0x00000000
    XCERE0 = 0x00000000
    PCR = 0x00000500
    RCERE1 = 0x00000000
    XCERE1 = 0x00000000
    RCERE2 = 0x00000000
    XCERE2 = 0x00000000
    RCERE3 = 0x00000000
    XCERE3 = 0x00000000

    If I than run the test app the McBsp1 register is like it was in my app.
    I get a  CLKS1 clock, muts to high but it is there, and stil no FSR1 clock.
    It must have something to do with Mcbsp_init(). I can't/may give you my project but the test app has the same settings for the McBsp.
    I hope that you can find why the regs are not set correctly.

    Thanks and Regards,

    Roy 

  • Found it!!!

    I am using the LogicPD Zoom™ OMAP-L138 eXperimenter Kit. The FSR1 signal should be on J30-pin13 following the schematic. But it isn't.
    The FSR1 signal is on U6 pin 9. And when I get the signal from here, I get a clock! So the McBsp0 and 1 are working now next to each other.

    So the workaround like Steven described works after all.

    It is just a hardware misunderstanding.
    Thank you all for helping me with this problem.

    Regards,

    Roy 

     

    On the test app the registers are still not correctly set, but on my real app they are. The McBsp stuff is the same.