• State TI Thinks Resolved
  • Locked Locked
  • Replies 13 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 1271 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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/66AK2G12: SPI register access issue in PRU

Yong Yang
Prodigy 100 points

Part Number: 66AK2G12

Tool/software: Code Composer Studio

I use K2GEVM to do some interface verification.I want to use the PRU to access some SPI device.

I found the SPI register read is OK, I could get the SPIREV content by constant table or global address(base addr:0x21805400/0x21805C00). But the SPI register write operation is not OK.(checked this by read back SPI register and see register contents in ARM site). I can write the SPI register in ARM, so the SPI hardware should be OK.

this is the config in my PRU CCS project:

 SPI0 : org = 0x21805400 len = 0x00000200 CREGISTER=6


 volatile __far pruSpi CT_SPI0 __attribute__((cregister("SPI0", far), peripheral));

 

Could you provide me some demo code in C how the PRU operate the SPI register?

BTW, I found there is only 2 SPI interface in the constant table, if I want to use 3 or 4 SPI in PRU, what should I do by using constant table? The access by global address may be a little slow for me.

  • 0
    TI__Guru**** 161600 points
    Can you share which Processor SDK RTOS version are you using?

    Best Regards,
    Yordan
  • 0 in reply to Yordan Kovachev
    Prodigy 100 points

    We run the K2G according pdk_k2g_1_0_10 without RTOS.

    I used pru-software-support-package(release 5.0) for the PRU test. I use a CCS K2G PRU project example as baseline, and found the SPI register read back don't change after writing a value in the PRU core. The result is the same, no matter access SPI register by constant table or by global address. As a contrast, I write/read back the UART/timer register by constant table in PRU, it's OK. Meanthile, the SPI register write/read back in the ARM core is OK.

    Is there any global cofiguration limit SPI write operation in PRU?

    Could you give me some advice or provide a PRU CCS demo contains SPI access?

  • 0 in reply to Yong Yang
    TI__Mastermind 43296 points
    Hi,

    The PRU cores within each PRU-ICSS have access to all resources on the K2G SoC. If you follow the steps in TRM Table 11-3376. SPI Master and Slave Mode Initialization, which step (register) that you are not able to write/read back from PRU?

    We have the PRU SPI example code based on bigbang (www.ti.com/.../TIDEP0033 ), don't really have an example of using SPI from SoC. Also as you found, there is only 2 SPI base address in constant table, you have to use global address for accessing 3rd and 4th SPI.

    Regards,
    Garrett
  • 0 in reply to Garrett Ding
    Prodigy 100 points

    hi, Garrett:

    According to the steps in TRM Table 11-3376, it failed in the second step(Take the SPI module out of reset). I found the SPIGCR0.RESET is also 0 after this step. The other steps are the same. I have check the readback in several way, such as read back at PRU site, see global address contents at ARM site, or see the Registers contents at ARM site in the CCS window. In the other hand, the SPI register read is OK, I can get the SPIREV contents 0x4A050300 normally. So, it confused me very much.

    for the SPI example you mentioned, I will study it later. thanks for your suggestion.

  • 0 in reply to Yong Yang
    Prodigy 100 points
    hi, Garrett:
    I have roughly studied the SPI example you mentioned.
    It's written by assemble language, I'm not well with this. It's built in AM437X, and it seemly operate SPI by GPI/GPO rather than the SPI peripheral interface, right?
    I can't run it because my test platform is EVMK2G.
  • 0 in reply to Yong Yang
    TI__Mastermind 43296 points

    Hi,

    As you are able to read/write UART/timer(1-4) which are from the same power domain source LPSC6, SPI should be able to out of reset if you write 1 to SPIGCR0. Let me check internally if we are missing anything here and then get back to you.

    That's right - the SPI example shows how to use GPI/GPO as SPI signals rather than SPI peripheral in the SoC.

    Regards,
    Garrett

  • 0 in reply to Garrett Ding
    Prodigy 100 points

    hi

    yes, I can read/write UART like this, I can see the readback is 0x0C in my CCS window.

        ulTmp = 0;
        CT_UART1.IER = 0xFC;
        ulTmp = CT_UART1.IER;

    For SPI peripheral, I can only read, write operation is not valid.

        CT_SPI0.SPIGCR0 = 0;
        CT_SPI0.SPIGCR0 = 1;                 //take SPI out of reset

        ulTmp = 0;
        ulTmp = CT_SPI0.SPIGCR0;        //read back is still 0

        ulTmp = 0;
        ulTmp = CT_SPI0.SPIREV;          //get the TI internal data 0x4A050300 normally

  • 0 in reply to Garrett Ding
    Prodigy 100 points

    Hi, Garrett:

    Did you find anything else we could check?

    We have tried to modify the power and clock configuration these days, and the result is the same.

    We have bought the EVM for a very long time, and the DSP chip is K2G02. Is it possible that this question is related to the EVM or to the K2G02?

  • 0 in reply to Yong Yang
    TI__Mastermind 43296 points
    Hi,

    There is really no special configuration for the SPI access from host per my discussion with our team.
    Do you modify the power and clock in GEL or host? Would it be possible to post your project here so I can try to reproduce?

    Regards,
    Garrett
  • 0 in reply to Garrett Ding
    Prodigy 100 points

    Hi,

    yes, here is the CCS project and gel file, thanks!

    My CCS version is 7.4.0.00015, and My PRU compiler is TI v2.3.1.

    evmk2g_armorg.gelK2G_PRU.zip

  • 0 in reply to Yong Yang
    TI__Mastermind 43296 points
    Hi,

    I was able to reproduce the SPI access issue with the project you shared, thank you.

    Unfortunately, the SPI module in K2G implements certain MMR bits as RWP which means that they can only be written in Privilege (supervisor) mode. This includes not only the nRESET bit in GCR0 but bits in many other registers as well. The PRU-ICSS in K2G doesn’t implement the priv signal on its VBUSP master ports, so there is no way for it to gain write access to those bits. We have submitted a ticket to add these details in a future TRM release.

    You need either implement PRU-ICSS GPIO based SPI interface or access SPI from ARM then share data with PRU if needed.

    Regards,
    Garrett
  • 0 in reply to Garrett Ding
    Prodigy 100 points

    Hi

    Got it, thank you.

    For now, this problem only happen in SPI module, other module, such as I2C, is OK. Am I right? BTW, is this problem the same in K2G12 and in K2G02?

    Do you have a schedule to fix this problem in the future and about how long we could get the new released chip?

  • 0 in reply to Yong Yang
    TI__Mastermind 43296 points
    Hi,

    Yes for now the problem is only known with the SPI module (we haven't checked all other modules yet). The problem is the same in K2G12 and K2G02. We don't have a schedule to address this other than to add the details into future TRM releases.

    Regards,
    Garrett