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.

CCS/AM6548: AM65x IDK SPI receiver problem

Part Number: AM6548
Other Parts Discussed in Thread: SYSCONFIG,

Tool/software: Code Composer Studio

Hello Everybody!

I would like to connect something to an SPI port of IDK.

I can send but can not receive.

I have found J20 connector where signals of MCSPI1 port are available.

spiInitCfg driver table has 5 entries:

Index

baseAddr

SPI port

0

0x40300000

MCU_MCSPI0

1

0x40310000

MCU_MCSPI1

2

0x40320000

MCU_MCSPI2

3

0

 

4

0

 

I have hacked the table by copying index 2 to index 3 and set the base address to MCSPI1 to reach that port:

    SPI_v1_HWAttrs spi_cfg;

    SPI_socGetInitCfg(2, &spi_cfg);
    spi_cfg.baseAddr = CSL_MCSPI1_CFG_BASE;
    SPI_socSetInitCfg(3, &spi_cfg);

And here is the initialization of SPI port:

    SPI_init();

    /* SPI initialization */
    SPI_socGetInitCfg(instance, &config);

    /* configuration example master see:
     * ti/pdk_am65xx_1_0_7/packages/ti/drv/spi/example/mcspi_slavemode */
    config.enableIntr = false;
    config.chNum = 0U;

    SPI_socSetInitCfg(instance, &config);
    /* Initialize SPI handle */
    SPI_Params_init(&params);
    params.transferMode = SPI_MODE_BLOCKING;
    params.transferCallbackFxn = NULL;
    params.transferTimeout = SemaphoreP_WAIT_FOREVER;
    params.bitRate = 12000000U;

    handle = SPI_open(instance, &params);

And then I sent data using Index 3 and could see CLK, CS and MOSI signals on pins of J20 connector by scope.

I used bool SPI_transfer(SPI_Handle handle, SPI_Transaction *spiTrans) fuction

 

Till now it is still OK.

 

Then I wanted to test the SPI input too, therefore I connected MISO input to MOSI output with a jumper (J20/2 – J20/1) and expected that the transfer function gets back the sent data.

 

    uint32_t loopCtr = 0;
    uint32_t readbackValue = 0x55555555U;
    while (true)
    {
        loopCtr++;
        ret = spi.transmit((uint8_t *)&loopCtr, (uint8_t *)&readbackValue, sizeof(loopCtr));
        if ( loopCtr == readbackValue ) {
            gpio.reset(USER_LED1);
            gpio.toggle(USER_LED0);
        }
        else {
            gpio.reset(USER_LED0);
            gpio.toggle(USER_LED1);
        }
        Task_sleep(20); /* suspend task*/
    }

(spi.transmit function calls SPI_transfer of course)

 

And here is my problem: I got 0 in readbackValue instead of the sent value always.

 

Connection to J20/2 pin is OK, I could see MOSI signal on it when changed DPE1 & DPE0 bits of MCSPI_CHCONF_1 register from 0b10 to 0b01 (or 0b00)

I suppose that input selector (IS) bit of MCSPI_CHCONF_1 can be used for internal loopback.

 

Here are my results 

IS

DPE1

DPE0

J20/1

J20/2

redbackValue

1

0

0

OK

OK

0

0

0

0

OK

OK

0

1

1

0

OK

-

0

0

1

0

OK

-

0

1

0

1

-

OK

0

0

0

1

-

OK

0

 OK means that MOSI signal was seen on that pin by scope.

- means inactivity, i.e. low level on that pin.

And I have never get back good value.

 

Memory browser window was active during my debug session becasue I watched / changed the SPI registers there.

Debugger may disturb operation when it reads registers unexpectedly (to update the browser window) therefore I have turned it off and repeated the SPI transfer,  but got the same 0 result.

Register content from memory bowser @ 0x02110100

MCSPI1_CFG_MCSPI_REVISION
0000002B    00000000    00000000    00000000
MCSPI1_CFG_MCSPI_SYSCONFIG
00000308
MCSPI1_CFG_MCSPI_SYSSTATUS
00000001
MCSPI1_CFG_MCSPI_IRQSTATUS
00020001
MCSPI1_CFG_MCSPI_IRQENABLE
00000000
MCSPI1_CFG_MCSPI_WAKEUPENABLE
00000000
MCSPI1_CFG_MCSPI_SYST
00000000
MCSPI1_CFG_MCSPI_MODULCTRL
00000001
MCSPI1_CFG_MCSPI_CHCONF_0
180603C8
MCSPI1_CFG_MCSPI_CHSTAT_0
0000002E
MCSPI1_CFG_MCSPI_CHCTRL_0
00000000
MCSPI1_CFG_MCSPI_TX_0
00000000
MCSPI1_CFG_MCSPI_RX_0
00000000

What is wrong here? Howe can I receive on SPI?

Best regards

Kalman

  • Hi Kalman,

    >>I have hacked the table by copying index 2 to index 3 and set the base address to MCSPI1 to reach that port:

    There are 5 entries in the spiInitCfg structure for main domain MCSPI including MCSP1 (soc\am65xx\SPI_soc.c), were you looking into MCU_MCSPI?

    {
    #if defined (__aarch64__)
    /* main domain */
    CSL_MCSPI1_CFG_BASE,
    CSL_GIC0_INTR_MCSPI1_BUS_INTR_SPI,
    #else
    /* mcu domain */
    CSL_MCU_MCSPI1_CFG_BASE,
    CSL_MCU0_INTR_MCSPI1_INTR_SPI,
    #endif

    Regards,
    Garrett

  • Hello Kalman,

    did you verify the padconf settings for your pins?

    I'm not 100% sure if the AM6X had that requirement, but often the clock pin needs to have input enabled in master mode too. I can check or setup tomorrow at the office.

    Regards,

    Dominic

  • Here's the note from the TRM that I was thinking of:

    NOTE: For SPI[3-0]_CLK and MCU_SPI[1-0]_CLK signals to work properly, the RXACTIVE bit of
    the appropriate CTRLMMR_WKUP_PADCONFIGx/ CTRLMMR_PADCONFIGy registers
    should be set to 0x1 because of retiming purposes.

  • Hi Garrett,

    my code was built for R5F core, then I suppose that is the reason why the table is filled with 3 MCU_SPI addresses. But I must use MCSI1 port, because it is available on J20 connector of IDK.

    BTW: this table should contain entry for ALL available ports, i.e. 8 in this case. All core must be able to access all ports, am I right?

    Regards

    Kalman

  • Hi Dominic,

    yesssssssssssss :-)

    I followed your instruction regarding pad config, and found this:

    CTRL_MMR0_CFG0_CTRLMMR_PADCONFIG116 CS0
    00010000
    CTRL_MMR0_CFG0_CTRLMMR_PADCONFIG117 CS1
    00010000
    CTRL_MMR0_CFG0_CTRLMMR_PADCONFIG118 CLK
    00010000
    CTRL_MMR0_CFG0_CTRLMMR_PADCONFIG119 D0
    00050000
    CTRL_MMR0_CFG0_CTRLMMR_PADCONFIG120 D1
    00050000

     RXACTIVE for SPI clock must be set (PADCONFIG118 = 0x0005000)! Otherwise the shift register input can not get the actual incoming data (not even at local loopback by CHCONFx.IS bit) .

    I still do not unerstand the reason, because PinMux tool has shown activated Rx at all SPI related pins in c:\ti\pdk_am65xx_1_0_7\packages\ti\board\src\am65xx_idk\am6548_idk.pinmux file.

    I have to check the generated files if they are not consistent with pinmux file, or where are they turned off.

    BUT

    the driver should take care of this setting according to actual mode (Tx/Rx; Tx only; Rx only)

    Thanks for your help.

    Regards

    Kalman