• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 99 subscribers
  • Views 763 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

McASP driver on OMAP-L137 and SYS/BIOS6

Rembrand van Lakwijk1
Prodigy 110 points
Other Parts Discussed in Thread: OMAP-L137, CCSTUDIO

I've been working with the EVM OMAP-L137 using SYS/BIOS 6 and CCSv5 for some time now, and I got most of the PSP working; I can serve web pages from the C6747 using the NSP/NDK and use GPIO. Now I've been trying to get the McASP driver from PSP 1.30 to work on SYS/BIOS 6 with less success; when I try to run the McASP demo master, I get the following output:

[C674X_0] Mcasp EVM-EVM Sample application.
Non primed Mode testing..
TX Done
Check slave for the data receive status
Primed Mode testing......

after which the program hangs waiting for a semaphore in SIO_reclaim() in the main task. I have also tried running the demo in CCStudio 3.3, but that won't let me load the binary onto the C6747; it complains about the image being for a different target (which I find very strange, since it is supposed to be specifically built for the evmOMAPL137).

Running the demo from CCSv5 with SYS/BIOS6, when I attach a logic analyzer to EXP_ACLKX1 or EXP_AXR1[5] it doesn't show any activity, leading me to believe the McASP is not doing anything at all, but I have no clue why.

To configure the EDMA3 i have used the edma3_lld_02_11_06_01 package, in combination with bios_edma3_drv_sample_omapl137_cfg.c, bios_edma3_drv_sample.h, bios_edma3_drv_sample_init.c and bios_edma3_drv_sample_cs.c from that same package copied into my project folder. And ofcourse to make it all compile, some modifications were made to the include paths in those files as well as the mcasp driver.

I was hoping that someone could provide me some guidance as to how to debug this situation; as it is, it appears to simply not work without giving me any error messages or other clues as to what's wrong.

EDIT: When I attach a scope to the EXP_ACLKX1 pin, I do see a signal that looks like a clock, but at an amplitude of only 75mV. I've checked the relevant registers;  in PINMUX9, PINMUX9_15_12 is set to ACLKX0, and in PDIR ACLKX is set to OUTPUT. This should be enough to expose the clock on the EVM 'audio expansion' header on pin 58, right?

EDIT 2: The low voltage was due to a buffer being disabled when pin 74 on the audio expansion connector is not connected. I've patched this with a wire bridge and am now seeing a 3.3V square wave at 4.8MHz. So I guess the McASP is working. How to proceed from here?

EDIT 3: Some more info that might be useful for debugging this problem: with a scope attached to AXR1[5], ACLKX1 and AFSX1, all signals seem to be fine during the 'non primed mode testing'; it looks like it's transmitting frames of data (although I have no way of verifying that the data is correct). When the 'primed mode testing' starts, the activity LED turns off after a while and AFSX1 and AXR1[5] do not show any activity anymore. ACLX1 keeps going just like it was in 'non primed mode'.

EDIT 4: It came to my attention that after prime() is called the very first time, the EDMA3 IPR shows that interrupt 3 is pending. This bit is never reset until the system is restarted. As of yet I have no idea whether this is normal behaviour, or what interrupt 3 signals. I guess I will look into this after the weekend.

  • 0
    TI__Expert 7290 points

    Hello Rembrand van Lakwijk1,

    Can you please specify the SYS/BIOS version being used?

    If you are using the recent version (Eg: bios_6_34_02_18), then it has the IOM driver model which can be accessed using the GIO APIs. Please refer the SYS/BIOS userguide for the usage of GIO APIs.

    Note: SIO APIs can not be used in SYS/BIOS6.

    You can refer the SYS/BIOS IOM driver implementation for C6748 (not OMAPL137) in the link http://software-dl.ti.com/dsps/dsps_public_sw/psp/BIOSPSP/03_00_01_00/index_FDS.html  . Please refer the PSP driver implementation and its usage in the example (source file and .cfg file). This PSP does not have the McASP read/write example, instead it has audio example which internally uses mcasp.

    Regards,

    Sandeep

  • 0 in reply to Sandeep Krishnaswamy
    Prodigy 110 points

    Hi Sandeep,

    I am indeed using BIOS 6.34.2.18. According to your suggestion I dropped the SIO demo and in stead tried to get GIO with the PSPBIOS 3 audio demo to work, modified to only transmit random data over McASP1 (in stead of echoing received data). I modified the BIOSPSP 3.0 McASP driver to use the CSLR headers from PSP 1.30 for OMAPL137 support.

    What I am seeing now is exactly what I saw at the first time (using SIO and a port of the old PSP 1.30): using 1 buffer it transmits valid data (i assume it is valid; each time I step through the code, once it hits GIO_issue() i see the same data pattern on the scope). When using 2 or more buffers, it hangs on GIO_reclaim().

    Also, even though with 1 buffer it seems to work, the data stream is not continuous; it transmits data for around 6.5ms, then pauses for around 15ms. This repeats. GIO_reclaim() also returns with IOM_EABORT each time. I suspect that somehow it misses a transfer completion, but I have no idea how to debug this. Could you offer me some guidance in this area?

    Thanks in advance,

    Rembrand

    EDIT: I've noticed that while transmitting with a single buffer (the only mode that doesn't make the system hang), a few registers assume values that I think shouldn't be seen while transmitting:

    - XFRST switches between ACTIVE and RESET

    - XSMRST does the same

    - XSRCLR switches between CLEAR and ACTIVE

    - XCKFAIL is always YES

    - XSYNCERR switches between YES and NO

    The delay between transmissions seems to be spent inside Mcasp_swiTxFifo(); the execution graph is shown below.

    mcasp_test_Task() is the function that continuously reclaims, fills and issues the buffer. I hope this helps.

  • 0 in reply to Rembrand van Lakwijk1
    TI__Expert 7290 points

    Hi Rembrand,

    How many bytes are you transmitting?

    Can you share the application?

    Thanks and Regards,

    Sandeep

  • 0 in reply to Sandeep Krishnaswamy
    Prodigy 110 points

    Hi Sandeep,

    The demo is configured to transmit 1024 32-bit samples at a time. I have not changed this.

    This sample project is available at https://dl.dropbox.com/u/33824394/McASP-PSP3-test.zip.

    Some pictures that might be helpful to illustrate the problem:

    The output of the AFSX1 (frame sync):

    The width of the peaks is about 6.8ms. This is exactly what we would expact, seeing as 1024 samples / 150KHz = 6,8267ms. This suggests the packets are fully transmitted.

    Zoomed in to one of the data areas:

    150KHz sample rate. I am not sure if this is correct according to the config, but if we assume it is, the rest looks fine.

    The data line, AXR1[5]:

    600KHz. This is expected, since I fill the entire buffer with bytes with value '1'. At 4 bytes per word, 150KHz*4=600KHz.

    So it seems the issuing of the buffer is done correctly, only the reclaiming is failing. I should probably also mention that when the debugger is attached in CCSv5, in stead of a 15ms pause between packets, this increases to about 95ms. I could imagine this being caused by the System_printf()s.

    Thanks for looking into this! I really am at a loss.

    ----- EDIT -----

    I discovered some incompatibilities between bios_edma3_drv_sample_omapl137_cfg.c and sample_c6748_int_reg.c, causing the EDMA3 interrupts to not be registered. I fixed this, and now I get a single burst of 6.8ms of data (one packet). After that, this happens:

    Assertion failed, (0 != timeout), file ../mcasp/Mcasp.c, line 3889

    Which is a timeout occurring in mcaspBitSetGblXCtl(), which is trying to set the XFRST bit (trying to activate the frame sync generator). Probably still some kind of interrupt problem, I'll keep searching... I've updated the sample project zip to reflect the changes in bios_edma3_drv_sample_omapl137_cfg.c.

    ----- EDIT 2 -----

    I think I've found the source of the problem: the EDMA3 completion ISR hangs while checking for pending interrupts. This happens in edma3resmgr.c, in the while loop on line 5241:

    while ((Cnt < EDMA3_RM_COMPL_HANDLER_RETRY_COUNT) && ((indexl != 0u) || (indexh != 0u))) { ...

    It appears this is a bug that happens because the OMAPL137 only has 32 TCCs. This means that in this loop, indexh is never set (to 0), thus the loop continues until a timeout occurs. I believe this can be fixed by changing line 5244 from:

    indexl = 0u;

    to:

    indexh = indexl = 0u;

    However, I have not been able to test this patch myself; whenever I try to rebuild the edma3 lld package, the build fails with the following message:

    make[1]: *** No rule to make target `c:/ti/edma3_lld_02_11_05_02/packages/ti/sdo/edma3/drv/lib//debug/edma3_lld_drv.a674', needed by `bin/ti816x-evm/edma3_drv_ti816x_sample_c6xdsp_debug.x674'. Stop.
    make[1]: Leaving directory `c:/ti/edma3_lld_02_11_05_02/examples/edma3_driver/evmTI816x'
    make: *** [edma3_drv_ti816x-evm_674_example] Error 2
    make: Leaving directory `C:/ti/edma3_lld_02_11_05_02/packages'

    I have tried driver versions 02.11.06.01 and 02.11.05.02, compiling against BIOS 6_34_02_18 and XDCtools 3_24_05_48, both with the exact same result. I have no clue where to start searching for where the build fails...

  • 0 in reply to Rembrand van Lakwijk1
    TI__Mastermind 18320 points

    Rembrand,

    It appears that Sandeep will not be able to offer up any further advice for you.  I have moved this thread over to the OMAP-Lxx forum in hopes that the people monitoring it will be able to offer up additional help.

    Dave

  • 0 in reply to David Friedland
    Prodigy 110 points

    Recompiling the McASP driver with Mcasp_LOOPJOB_ENABLED seems to have fixed the hangups; I now have a steady stream of data. I don't know whether it is repeating samples to fill in gaps at the moment, and for my purpose this doesn't really matter; I intermittently need to sample an incoming data stream, rather than provide a continuous outbound stream.

    The problem with 'indexh' not being set turned out to indeed be a bug, but not a very critical one; the only thing it did was let the ISR run longer than needed, because the pending interrupt check loop would be run for 10 times (if I recall correctly) in stead of just one.

    I am a bit disappointed that I could not find the source of the problem (why doesn't it work with the loopjob disabled?), but seeing as it works as well as I need it to, I don't really care anymore. Case closed :-)