TMDSCNCD28388D: microSD card read write issue

Ravi,

Due to US holidays, subject matter expert is out of office next week. Please expect response by Jan 5 or 6. Sincere apology for inconvenience.

Thanks for you patience while I was out of the office. Can you share what updates you've made to the code to port it to F28388D? I'm guessing it was mostly GPIO changes?

Do you have access to a logic analyzer or oscilloscope or something you can use to check the SPI signals? Although I suppose that might be difficult if you're using the on board micro SD slot. You could probably use an input XBAR connected to an output XBAR to bring them out to an accessible pin though.

Whitney

Sir,

I'm attaching my file. I have made changes for SPI-C lines, using a 4 GB microSD. main file is in card\port\sd_card.c.

Apart from above, others changes include:

baud rate 

creating and writing in a file

Sorry for any incomplete info from my side as I'm a beginner on microSD and FAT filesystems.

I will read and try to implement using:  input XBAR connected to an output XBAR.

Hopefully with enough understanding I want to have SD card firmware update & datalogger functionalities. 

spi_test_0.4.rar

Your GPIO configurations don't look right. For pins 100-102, the MUX fields should be 2 and the GMUX should be 1 (see how in the data sheet the SPI C options are in column 6). For GPIO 103, the mux values should be 0 since it is supposed to be a GPIO.

Make sure you fix it in both power_on() and in send_initial_clock_train().

Whitney

Sir,

I did try:

GpioCtrlRegs.GPDMUX1.bit.GPIO100 = 2; // for GPIO 100, 101, 102

GpioCtrlRegs.GPDMUX1.bit.GPIO103 = 0; // for GPIO 103

or

GPIO_SetupPinMux(100,0,6); // for GPIO 100, 101, 102

Made changes in power_on(), send_initial_clock_train()

but no improvement, getting same error of FR_NOT_READY . 

Sir, is there any sample to setup XBAR to monitor SPI-C lines?

If you want to write to the mux registers directly, you need to write to both GPDMUX1 and GPDGMUX1. The GPIO_SetupPinMux() function writes to both, so that approach should work at least.

We don't have any examples that use the XBAR that way. It would look something like this (note that I haven't tested this myself):

    EALLOW;
    
    // XBAR input 1 will take its value from GPIO100
    InputXbarRegs.INPUT1SELECT = 100;
    
    // Configure MUX1 of OUTPUTXBAR3 to be INPUTXBAR1
    OutputXbarRegs.OUTPUT3MUX0TO15CFG.bit.MUX1 = 1;

    // Enable MUX 1 of OUTPUTXBAR3
    OutputXbarRegs.OUTPUT3MUXENABLE.bit.MUX1 = 1;
    
    EDIS;
    
    // GPIO 14 is configured to OUTPUTXBAR3
    GPIO_SetupPinMux(14, 0, 6);

See if this makes the SPI signal on GPIO100 observable on GPIO14. Use the data sheet and the XBAR chapter in the TRM to adjust the path as needed.

Whitney