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.

TMS320F28388D: SPI-A on CPU-2 not working, on CPU-1 seems to work

Part Number: TMS320F28388D

My application uses the TI TMS320F28388D with the Micron MT25q serial NOR flash memory connected to SPI-A. Assigned GPIO pins are:

GPIO16 = SPIA SIMO
GPIO17 = SPIA SOMI
GPIO18 = SPIA Clock
GPIO19 = SPIA Chip Select
GPIO98 = Device Write Protect
GPIO99 = Device Hold

GPIO 16-19 are reassigned to their SPI-A functions. GPIO 98 and 99 are programmed as GPIO Outputs.

For resource management reasons it is strongly preferred that the flash device run on CPU2. When I configure it to run on CPU1 it appears to work correctly, i.e. sending a Read Status Register command to the SPI results in correct activity on the SPI Clock, Chip Select and Data pins. However if I assign SPI-A and the two GPIO Outputs to CPU2, the GPIO Outputs (98 and 99) continue to work correctly but SPI-A does not... sending a Read Status Register command results in no activity on any of the SPI pins.

Below I have included the SPI Initialize function I use to set up the GPIO pins and transfer control to CPU2. This function is executed prior to CPU1 releasing CPU2's Reset so CPU2 can start. On the CPU2 side I don't do any additional configuration.

Something is missing here, probably something obvious, but I can't figure out what. Any assistance is greatly appreciated. And if you can point me to the TI documentation that explains it all, that would be even better... I am unable to find anything relevant in the 5000++ page user manual or 300+ page data sheet. At this point I am not even 100% certain that SPI-A can be run on CPU2 with these pin assignments, although I have not been able to find any indication that it cannot.

Sorry if the formatting / indentation is a bit off in the following source code, can't seem to figure out how to get "source code" formatting to work on this forum, also can't seem to get "preview" to work, hope the following source code comes out OK..

void FlashSpiInit( void )
{
// Program the SIMO pin (Slave Input Master Output)
//
GPIO_setMasterCore( 16, GPIO_CORE_CPU1 );
GPIO_setPinConfig( GPIO_16_SPISIMOA );
GPIO_setPadConfig( 16, GPIO_PIN_TYPE_PULLUP );
GPIO_setQualificationMode( 16, GPIO_QUAL_ASYNC );

// Program the SOMI pin (Slave Output Master Input)
//
GPIO_setMasterCore( 17, GPIO_CORE_CPU1 );
GPIO_setPinConfig( GPIO_17_SPISOMIA );
GPIO_setPadConfig( 17, GPIO_PIN_TYPE_PULLUP );
GPIO_setQualificationMode( 17, GPIO_QUAL_ASYNC );

// Program the Clock pin
//
GPIO_setMasterCore( 18, GPIO_CORE_CPU1 );
GPIO_setPinConfig( GPIO_18_SPICLKA );
GPIO_setPadConfig( 18, GPIO_PIN_TYPE_PULLUP );
GPIO_setQualificationMode( 18, GPIO_QUAL_ASYNC );

// Program the CS/STE pin
//
GPIO_setMasterCore( 19, GPIO_CORE_CPU1 );
GPIO_setPinConfig( GPIO_19_SPISTEA );
GPIO_setPadConfig( 19, GPIO_PIN_TYPE_PULLUP );
GPIO_setQualificationMode( 19, GPIO_QUAL_ASYNC );

// Program the Write Protect pin, leave it as a GPIO and make it an output
//
GPIO_setMasterCore( 98, GPIO_CORE_CPU1 );
GPIO_setPinConfig( GPIO_98_GPIO98 );
GPIO_setPadConfig( 98, GPIO_PIN_TYPE_PULLUP );
GPIO_setQualificationMode( 98, GPIO_QUAL_ASYNC );
GPIO_setDirectionMode( 98, GPIO_DIR_MODE_OUT );

// Program the Hold pin, leave it as a GPIO and make it an output
//
GPIO_setMasterCore( 99, GPIO_CORE_CPU1 );
GPIO_setPinConfig( GPIO_99_GPIO99 );
GPIO_setPadConfig( 99, GPIO_PIN_TYPE_PULLUP );
GPIO_setQualificationMode( 99, GPIO_QUAL_ASYNC );
GPIO_setDirectionMode( 99, GPIO_DIR_MODE_OUT );

SPI_disableModule( SPIA_BASE ); // Put SPI into reset before configuring

// SPI configuration. Use a 15MHz SPICLK and 8-bit word size.
//
SPI_setConfig( SPIA_BASE, DEVICE_LSPCLK_FREQ, SPI_PROT_POL1PHA0, SPI_MODE_MASTER, 15000000, 8 );

// FIFO configuration; associated interrupts will be enabled when other SPI
// interrupts are enabled
//
SPI_enableFIFO( SPIA_BASE );
SPI_resetTxFIFO( SPIA_BASE );
SPI_resetRxFIFO( SPIA_BASE );

SPI_enableModule( SPIA_BASE ); // Configuration complete. Release Reset to enable the module.

// All seem to work correctly when run on CPU1. If I execute the following
// to switch control to CPU2, the GPIO pins 98 and 99 work but the SPI
// device does not.

// I read on E2E that the GPIO pins that have been reassigned to SPI do not
// need to be reassigned to CPU2, only the GPIOs (WP and HOLD) and the SPI
// device need to be reassigned here. Tried both ways and didn't appear to
// make any difference.
//
GPIO_setMasterCore( 16, GPIO_CORE_CPU2 );
GPIO_setMasterCore( 17, GPIO_CORE_CPU2 );
GPIO_setMasterCore( 18, GPIO_CORE_CPU2 );
GPIO_setMasterCore( 19, GPIO_CORE_CPU2 );

GPIO_setMasterCore( 98, GPIO_CORE_CPU2 );
GPIO_setMasterCore( 99, GPIO_CORE_CPU2 );

SysCtl_selectCPUForPeripheral( SYSCTL_CPUSEL6_SPI, 1, SYSCTL_CPUSEL_CPU2 );

return;
}

  • Your SPI pins configurations look correct. Did you check whether SPI register are visible from CPU2?

    Did you make sure to call function  SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_SPIA) from CPU2 side?

    Note that the peripheral clock should be enabled from respective peripheral owner core .

    Regards,

    Manoj

  • Good evening Manoj, and thanks for the response.

    It took a bit of searching to find a register that doesn't default to all zeros after reset, but I tried looking at the SPIFFTX and SPIFFRX registers. On the CPU1 side, with the switchover to CPU2 disabled, they show 0xE080 and 0x231F respectively; after switching them to the CPU2 side they show 0xA000 and 0x201F respectively. So...

    CPU1 = 0xE080 - Out of Reset, FIFO enhancements enabled, TX FIFO out of reset, transmit FIFO empty, TX FIFO interrupt has occurred. Looks reasonable except for the TX FIFO interrupt.

    CPU2 = 0xA000 - Out of Reset, FIFO enhancements disabled, TX FIFO out of reset, transmit FIFO empty, TX FIFO interrupt has NOT occurred.

    I don't think they should be different, but I don't know if that means CPU2 is unable to get a reliable read of the SPI's registers..

    As for 0x231F (CPU1) vs 0x201F (CPU2), it's telling me there are 2 words in the FIFO for CPU1 and none for CPU2. No idea where that's coming from or why they're different, I haven't sent any data out or back in the SPI port yet.

    Bottom line is I can't really tell if CPU2 is able to read the SPI registers correctly.

    As for SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_SPIA), yes that is being called on the CPU2 side. There is one function that came from someone (not me) that basically lights up the world, enables every clock for every peripheral including all four SPIs, and including this one. CPU1 releases CPU2's Reset after the SPI configuration and switchover is done, so SysCtl_enablePeripheral is definitely being called on the CPU2 side after the SPIA device has been assigned to CPU2.

    Is any of that helpful?

  • Are you configuring SPIA in CPU1 (or) CPU2? Since you are assigning SPI to CPU2, please configure SPI from CPU2 and check.

    When you run SPI configuration code from CPU2, make sure the register write to SPI registers go through.

    Regards,

    Manoj

  • Thanks, Manoj.  The MPU manual seems adamant that all such configuration must be done on CPU1 and only then should the device be reassigned to CPU2.  Anyway, I have been asked not to spend any more time trying to get this to run on CPU2, rather I should concentrate on getting it running on CPU1, and after it is running, revisit getting it moved over to CPU2.  So I will try what you suggest but it's going to be a little while before I can get to it.  When I can, I'll report back.

  • Okay, Can I close this thread for now? You can reopen this thread when you revisit this problem.

    Regards,

    Manoj

  • That'll be fine, thanks.  I don't really know which one of those buttons to push.. the issue isn't resolved, and yet your efforts (for which I thank you) didn't exactly NOT resolve the issue, won't know until I'm able to try it.

  • You don't have actions from your side. I'm marking "TI Thinks Resolved" because you're focusing on getting things correctly working on CPU1 and not actively working on CPU2 SPI debug. I cannot leave the tickets open.

    When you need to re-open the thread just reply to this thread, it will automatically re-open.

    Regards,

    Manoj