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.

Merging MMCSD and UPP Project Help

Expert 2370 points

Other Parts Discussed in Thread: OMAP-L138, OMAPL138, CDCE913

Hi,

I am using OMAP-L138 EVM and my intention is to write large amount of sampled data to SD card. I have working RTFS based MMCSD code to write data to SD card and BSL based UPP code to sample analog signal, respectively. However, when I add BSL code to RTFS based project, it compiles fine but doesn't work. 

Step-wise debugging revealed that it doesn't come back from this function result = mmcsdStorageInit(), to be more precise, it gets lost in the function given below which is defined in blkmedia.c and I don't see anything.

result = EDMA3_DRV_requestChannel(gBlkmediaSyncEdmaHandle,
&gBlkmediaIoChId,
&gBlkmediaIoTcc,
edmaEventQ,
&blkmediaIoEdmaCallback,
NULL);

You can have a look on the merged code routine.

Code Snippet:

void main()

{

USTIMER_init();
I2C_init(I2C0, I2C_CLK_400K);
I2CGPIO_init(0x20);

// Setup UPP

// UPP registers setup

// Setup ADC Clock

rtfsPosixInit();

/* initialize the PSC */
mmcsdPscInit();
Psc_ModuleClkCtrl(Psc_DevId_0, CSL_PSC_CC0, TRUE);
Psc_ModuleClkCtrl(Psc_DevId_0, CSL_PSC_TC0, TRUE);
Psc_ModuleClkCtrl(Psc_DevId_0, CSL_PSC_TC1, TRUE);
Psc_ModuleClkCtrl(Psc_DevId_1, CSL_PSC_CC1, TRUE);

/* Create semaphore for card insert/remove interrupt mode */
cardDetectSem = SEM_create(0, NULL);

}

Void task(Arg id_arg)
{
Int32 result;
Int id = (Int)id_arg;
char driveId[3];

printf("MMC/SD Application Task %d Starting.\n", id);

/* Configure MMC/SD */
configureMmcsd0(mmcsdGpioInputIsr);

printf("Configured MMC/SD card.\n");

/* Initialize for MMC/SD storage device */
result = mmcsdStorageInit();

if (result == SUCCESS) {
printf("Block Driver initialization succeeded.\n");
}
else {
/* Most likely not enough memory */
printf("Block Driver initialization failed, error = %d.\n", result);
return;
}

/* verify that the MMC/SD card is present before continuing */
PollDeviceReady();

/* Get drive letter associated with MMC/SD */
result = getdriveid(BFS_DEVICE_TYPE_MMC, 0 , 0, driveId);
if (result != -1) {
printf("Get drive ID DONE. %s\n", driveId);
}
else {
printf("Error getting drive ID.\n");
return;
}

/* Clear the partition */
result = clearPartition(driveId);
if (result == SUCCESS) {
printf("Clear partition DONE.\n");
}
else {
printf("Clear partition Failed, error = %d.\n", rtfserrno);
return;
}

/* Format the drive */
result = fmtdrv(driveId);
if (result == SUCCESS) {
printf("Formatting succeeded.\n");
}
else {
printf("Formatting failed, error = %d.\n", rtfserrno);
return;
}

printf("---Collecting samples from ADC---\r\n");
UPP->UPID0 = (uint32_t)&recv_buffer;//add next DMA transfer
UPP->UPID1 = 0x00010800; //1 lines 128 bytes per line
UPP->UPID2 = 0x00000800; //no offset between lines

printf("MMCSD File Operations Starting.\n");
doFileIO(driveId);

printf("Starting rtfs shell.\n");
bfs_shell();

/* Shutdown the MMCSD storage device */
result = mmcsdStorageDeInit();

if (result == SUCCESS) {
printf("mmcsdStorageDeInit succeeded.\n");
}
else {
printf("mmcsdStorageDeInit failed, error = %d.\n", result);
}
}

I don't have much technical knowledge about OMAP-L138 and peripheral so I have no idea what's going on. I will really appreciate your help.

Thanks.

Regards,

BAS

  • Hi,

    It's urgent, I would really appreciate any help on this ?

    Thanks.

    BAS

  • Hi BAS,

    I'm not familiar with what product or which version you're using so please bear with me... Can you please provides the product versions?

    On which core are you running this code?

    Does the MMCSD code work by itself (without the UPP "stuff")? Does the UPP code work without the  MMCSD code? Will this problem just happen when you combine them together?

  • Hi Tom,

    Thanks for your attention.

    I am using OMAP-L138 EVM with OMAPL138 SOM. Yes, MMCSD and UPP code runs just fine separately, problem occurs when I try to combine them. I am using following version of different packages.

    rtfs_1_10_02_32

    pspdrivers_01_30_01

    bios_5_41_07_24

    edma3_lld_01_11_01_04

    Actually I modified upp_bios_drv_v10 based UPP code to fit my requirement. Original code was bit complex for me because of the ECM module and other stuff. I used RTFS as base project and added codes from UPP project, it compiles fine but never return after this function result = mmcsdStorageInit().

    I used PINMUX utility to see if there is pin conflict but I think it is fine, don't know about GPIO though.

    Thanks.

    BAS

  • BAS,

    Can you step in the debugger into the mmcsdStorageInit() function to determine why it is not returning?  Is the CPU polling some register and not seeing an expected transition?  

    Also, what do you mean by “don’t know about GPIO though”?

    Thanks,
    Scott

  • Scott,

    I mentioned in the very first post that:

    Step-wise debugging disclosed that it doesn't come back from the function result = mmcsdStorageInit(), to be more precise, it gets lost in the function given below which is defined in blkmedia.c and I don't see anything.

    result = EDMA3_DRV_requestChannel(gBlkmediaSyncEdmaHandle,
    &gBlkmediaIoChId,
    &gBlkmediaIoTcc,
    edmaEventQ,
    &blkmediaIoEdmaCallback,
    NULL);

    I meant from previous statement that, I don't know if there is any GPIO conflict while merging two projects.

    You can see how main of the project looks like:

    Void main()
    {
    /* DSP/BIOS File System initialization */
    rtfsPosixInit();

    /* initialize the PSC */
    mmcsdPscInit();
    Psc_ModuleClkCtrl(Psc_DevId_0, CSL_PSC_CC0, TRUE);
    Psc_ModuleClkCtrl(Psc_DevId_0, CSL_PSC_TC0, TRUE);
    Psc_ModuleClkCtrl(Psc_DevId_0, CSL_PSC_TC1, TRUE);
    Psc_ModuleClkCtrl(Psc_DevId_1, CSL_PSC_CC1, TRUE);

    // init the us timer, i2c, and gpio expander for all to use.
    USTIMER_init();
    I2C_init(I2C0, I2C_CLK_400K);
    I2CGPIO_init(0x20);

    //setup UPP
    I2CGPIO_init(I2C_ADDR_GPIO_UI); //IO expander on UI board
    I2CGPIO_setOutput(I2C_ADDR_GPIO_UI, I2C_GPIO_UI_SELA, OUTPUT_HIGH);
    I2CGPIO_setOutput(I2C_ADDR_GPIO_UI, I2C_GPIO_UI_SELB, OUTPUT_LOW);
    I2CGPIO_setOutput(I2C_ADDR_GPIO_UI, I2C_GPIO_UI_SELC, OUTPUT_LOW); // only ADC is enabled

    //Setup ADC Clock
    CDCE913_setOutput(cdce913_output_2, 6); 

    // enable HWI7 (tied to ECM block 2; see TCF)
    //C64_enableIER(1 << 7);

    /* Create semaphore for card insert/remove interrupt mode */
    cardDetectSem = SEM_create(0, NULL);
    }

    When I disbale USTIMER_init, I2C_init, I2CGPIO_init and UPP setting up functions, it works fine. It clearly means that there is something which doesn't work together. 

    I look forward for your help.

    Thanks.

    BAS

  • BAS,

    OK, I didn’t see in your earlier post that you’d said the program “gets lost” in EDMA3_DRV_requestChannel().  What do you mean by “gets lost”?  Does the program crash, or does the CPU stay within that function, or one that it calls?  The more details you can provide the better...

    I’ve not used the products you are using, and don’t know if they are expected to work together without modification or not.  I expect that you may need to resolve the GPIO configuration uncertainty first, but that is just a guess.

    I just sent a ping internally to the EDMA team to comment about debugging the request channel call, and the driver team about using those products together...
     
    Scott

  • http://e2e.ti.com/cfs-file.ashx/__key/communityserver-discussions-components-files/355/7245.BAS_5F00_mmcsd.7z

    Scott,

    Thanks for your response.

    I attach my project if you or your team want to look deeper.

    I meant from previous comment that it doesn't come back from that function and kept running in some loop or I don't know. Here attached snapshot, you can see after executing mmcsdStorageInit(), it never halted at 'if' statement (never return), when I halted the processor, disassembly shows it is in some kind of loop. 

    First it should be clear that both projects can work together. I mentioned earlier that my limited knowledge about OMAP-L138 and peripheral is not sufficient to solve this problem. I will really appreciate yours or appropriate guys help to solve this problem ASAP. It is urgent as I have already spent much time alone to fix this but all in vain.

    Thanks.

    BAS 

  • I will really appreciate help dealing with this problem. I am really stuck and don't know what to do.

    Thanks.

    BAS

  • BAS,

    I just saw this post, and the one from two days ago.  I just sent another ping to the EDMA3 and driver teams asking for assistance.  

    Yes, it is clear that you have RTFS and UPP working independently, but not together in the same application.  I think there is a resource collision somewhere, but I'm not familiar with these products.

    The screenshot you posted indicates the CPU is running the RTDX “data pump”, which runs in the background from the DSP/BIOS idle loop.  It seems that the EDM3_DRV_requestChannel() function has blocked the task’s execution, waiting for a semaphore in the underlying resource manager.  And since all threads are blocked, the idle loop is running.  This is what it looks like is happening, but I’m not positive.

    Hopefully someone else can help you soon…

    Scott

  • I hope to get help from concerned people soon.

    Thanks.

  • Can I get anyone's attention over this post ?

    Thanks.

    BAS

  • Hi BAS,

    I'll ping on the EDMA team again, not sure why they haven't responded.

    In the meantime, can you check this thread out?  The problem in this thread sounds very similar to the one you are experiencing.

    http://e2e.ti.com/support/embedded/bios/f/355/t/112802.aspx

    Steve

  • Hi Steve,

    I am not using any interrupt with UPP project so that thread might not be useful but I will surely have a look. I will appreciate if someone from EDMA team helps me out soon.

    I wonder if clocking has some thing to do with my problem since EDMA and MMC/SD are getting clock from PLL0_SYSCLK2 [SPRUH77A, Page 135] ?

    Thanks.

    BAS

  • Steve,

    Your suggestion didn't help because I am not using any HWI for uPP project.

    I did some more digging by checking PINMUX setting, individual project don't use SPI1 but combined project uses SPI1 so there is a pin conflict between PINMUX4 and PIXMUX5 register which corresponds to I2C0 and SPI1. I am not sure if that's the problem but my two cents.

    I am still waiting for help from EDMA team. I can't do anything on my own at the moment and that's delaying my project.

    I really appreciate quick help.

    Thanks.

    BAS

  • Do you have any updates on my issue ? It's already been a month now.

  • I ran into something that sounds similar to this.  It was because my RTFS and UPP threads had higher priority than the Blkmedia_Task (2) so the initialization couldn't get past that step (the idea is described here http://e2e.ti.com/support/embedded/bios/f/355/t/130313.aspx)