• State TI Thinks Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 1901 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

RM48L952: SPI1 and SPI2 have same HalCoGen settings, but different outputs

John McLaughlin22
Prodigy 180 points
Part Number: RM48L952
Other Parts Discussed in Thread: HALCOGEN

I am trying to use the RM48L952 HDK board's SPI2 peripheral in Master mode. I originally used SPI1 and was able to verify the code and the HalCoGen settings as working. However, because this system also requires the Ethernet on the board and the HDK board has Ethernet and SPI1 muxed, I had to switch over to SPI2. I replicated the settings for SPI2 in HalCoGen, but the output is different. Attached are screenshots of my HalCoGen tabs for SPI1 and SPI2.

The code below are functions I am using to interact with my SPI slave. This code works when using SPI1, with the HalCoGen settings attached.3771.spi settings.zip

void init_spi_interface() {
	spiInit();

	data_config.CS_HOLD = 1;
	data_config.WDEL    = 0;
	data_config.DFSEL   = SPI_FMT_0;
	data_config.CSNR    = SPI_CS_0;
}

void send_spi_message() {

	uint16_t txBuf[] = {0x03U, 0x60U, 0xF4U, 0x6CU};

	spiTransmitData(spiREG2, &data_config, 4, txBuf);
}

The (correct) output of SPI1 is 03 60 F4 6C, whereas the (incorrect) output of SPI2 is 03 07 10. (Notice I only get a byte and a half rather than two bytes)

Is there something inherently different about SPI2 and SPI1 that would cause this?

Thank you,

John

  • 0
    Prodigy 180 points
    And for some extra details, I tested both SPI1 and SPI2 with two different boards (to determine if SPI2 was damaged) but got the same result.
  • 0
    Prodigy 180 points
    Going through the schematics for the development board, SPI2 is being routed to the microSD slot as well as the expansion header J10. That shouldn't interfere with the transmissions through J10, should it?
  • 0 in reply to John McLaughlin22
    TI__Guru 59540 points
    Hi John,

    Can you zip and post your project files including the HalCoGen .hcg and .dil files for the Halcogen project so I can have a closer look?

    The connections to the SD card should have any affect unless you have a card in the slot that might influence the data lines.

    Also, to be clear, I have to confirm that you have verified the data line input from the external device/source by means of a scope or protocol analyzer? It is important to know if the data lines represent the same data you are receiving or your expected data.

    Also, I see that you are experiencing the "jumbled" GUI issues that we sometimes see with halcogen. This is a result of your configured font size. In order for Halcogen to display correctly, it has to have the system font set to 100% or less. It, unfortunately, is not adaptable when a larger font is chosen. Apologies for that.
  • 0 in reply to Chuck Davenport
    Prodigy 180 points

    Here are all my HalCoGen project files: 8546.halcogen project.zip

    I have verified the data line going into the slave using a protocol analyzer. It's using the protocol analyzer that I was able to verify that SPI1 works, but SPI2 does not.

    And thank you for telling me what was up with the GUI. That was getting annoying.

    John

  • 0 in reply to John McLaughlin22
    TI__Guru 59540 points
    Hi John,

    thanks for providing the source and halcogen files. I took a quick look at them and nothing stuck out as an issue. I did confirm that the configurations in Halcogen are the same. I had trouble with that with the pictures you posted because of the GUI distortions. Anyway, I am going to be out of the office on business travel over the next week so I am going to forward your post to an associate to see if he can have a look too. Maybe a fresh set of eyes will spot the issue.
  • 0 in reply to Chuck Davenport
    TI__Guru**** 186196 points

    Hello John,

    I tested SPI2 on HDK this morning, it works without any problem. If you use an external SPI tool, you need to enable the CS hold mode. In CS hold mode, the chip select signal is held active at the end of a transfer until a control field with new data and control information is loaded into SPIDAT1. If the new chip select number equals the previous one, the active chip select signal is extended until the end of transfer with CSHOLD cleared, or until the chip-select number changes.

    This is the code I used in my test:

    /* USER CODE BEGIN (0) */
    /* USER CODE END */

    /* Include Files */

    #include "sys_common.h"

    /* USER CODE BEGIN (1) */
    #include "spi.h"
    /* USER CODE END */

    /** @fn void main(void)
    * @brief Application main function
    * @note This function is empty by default.
    *
    * This function is called after startup.
    * The user can use this function to implement the application.
    */

    /* USER CODE BEGIN (2) */
    uint16 TX_Data[16] = { 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F, 0x10 };
    uint16 RX_Data[16] = { 0 };

    /* USER CODE END */
    int main(void)
    {
    /* USER CODE BEGIN (3) */
    volatile uint32 SpiBuf, blocksize, i;
    spiDAT1_t dataconfig1_t;

    dataconfig1_t.CS_HOLD = TRUE;
    dataconfig1_t.WDEL = FALSE;
    dataconfig1_t.DFSEL = SPI_FMT_0;
    dataconfig1_t.CSNR = 0xFE;

    /* Enable CPU Interrupt through CPSR */
    _enable_IRQ();

    /* Initialize SPI Module Based on GUI configuration
    * SPI2 - Master ( SIMO, SOMI, CLK, CS0 )
    * */
    spiInit();

    /* Initiate SPI2 Transmit and Receive through Polling Mode*/
    for (i=0; i<100; i++){
    spiTransmitData(spiREG2, &dataconfig1_t, 16, TX_Data);
    }
    while(1);

    /* USER CODE END */

    return 0;
    }

    Teh SPI2 is configured as master, the baud rate is 1000Kbps, data length is 16bit. The SPI slave is Aardvark SPI/I2C adaptor. From the figure below, the txed data from SPI2 is the same as the rxed data on SPI adatpor (the data format is 16-bit, so they are 00 01 00 02 00 03...):

    TX_Data[16] = { 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F, 0x10 };

  • 0 in reply to QJ Wang
    Prodigy 180 points
    QJ,

    Thank you for your reply. We are actually starting to believe that the reason for this is due to a combination of a grounding issue and EMI interference.

    To resolve this issue, I'm looking at the low-EMI mode for these pins. I'm assuming that works to reduce possible EMI for the pins, but is there a tradeoff at all that I should worry about?
  • 0 in reply to John McLaughlin22
    TI__Guru**** 186196 points
    Hello John,

    If the problem is caused by EMI, why does the SPI1 work well? If the board or the test environment has bad EMI, both SPI1 and SPI2 should be affected.

    The low-EMI output buffer is enabled by setting the system module (GPCR1) register . Please let us know your test result, thanks.
  • 0 in reply to John McLaughlin22
    TI__Guru 59540 points
    John,

    It would be interesting to see if enabling the Low EMI feature impacts your results. Note that the Low EMI feature is primarily for outputs as it "softens" the edges of pulses so EMI is not generated by the MCU for rapidly changing signals and also pulls the output levels off the rails by a small amount.