• State
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 68 replies
  • Subscribers 35 subscribers
  • Views 1288 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.

TMDSCNCD263P: ECP: AM263P CC Inconsistency in Enabling 8D-8D-8D protocol in OSPI

Sanith goud Kothuri
Prodigy 170 points

Part Number: TMDSCNCD263P
Other Parts Discussed in Thread: SYSCONFIG

Hi Team,

Greetings of the day.

I’m currently working on the XIP feature using OSPI in 8D-8D-8D mode. To enable the required configuration, I followed the settings mentioned in the SDK’s SBL_OSPI_Multicore_elf example project and replicated the same steps in my custom bare-metal project.

While debugging the bare-metal code, I manually wrote some hardcoded values to the registers using the memory browser window. After issuing the Read Device ID command, I was able to successfully read both the Device ID and Manufacturer ID. Using a pointer to the flash address range, I was also able to read the correct data stored in the flash memory.

However, when I run the same code without step-by-step debugging (i.e., in one go), it does not work reliably. Sometimes it directly enters the while(1) loop, and at other times it gets stuck while reading the status register—the status register value remains 0xFF, and the code never exits from that state.

Could you please help me identify what might be causing this inconsistent behavior?

  • 0 in reply to Mayank Shadwani
    Prodigy 170 points

    Hi  

    Mayank Shadwani said:
    Could you please try re-installing CCS 12.8.1? This should ensure that all the necessary software repositories are properly configured during installation.

    I downloaded CCS 12.8.1 version executable from TI site and installed yesterday afternoon.

    while installing i checked custom installation and selected Sitara MCU AMxx all family series, C2000 series and TMS570 series.

    will this create any issue ?

  • 0 in reply to Sanith goud Kothuri
    TI__Intellectual 990 points

    Hi Sanith,

    Selecting multiple device families during custom installation (Sitara MCU AMxx, C2000, and TMS570) shouldn't cause any problems.

    That said, since your "Available Software Sites" is missing several expected options, I'd recommend performing a fresh re-installation of CCS 12.8.1. This will ensure that all necessary software repositories and components are properly initialized.

    Best regards,
    Mayank Shadwani

  • 0 in reply to Mayank Shadwani
    Prodigy 170 points

    Hi  

    I performed a fresh reinstallation of CCS 12.8.1 and upgraded the Sitara MCU Support Software to version 1.5.6 (the latest release).

    However, after running my code, the issue still persists, the data is still appearing in a shuffled order, as shown in the earlier screenshot.

    What might be causing this issue? Could you suggest any other possible solutions?

  • 0 in reply to Sanith goud Kothuri
    TI__Intellectual 990 points

    Hi Sanith,

    Thank you for reinstalling CCS 12.8.1 and updating to Sitara MCU Support Software version 1.5.6.

    To help us investigate the data shuffling issue further, could you please clarify which specific issue you're referring to:

    1. Incorrect GEL scripts causing the data display issue, or
    2. Incorrect device ID read resulting in shuffled data?

    Best Regards,
    Mayank Shadwani

  • 0 in reply to Mayank Shadwani
    Prodigy 170 points

    Hi    

    Mayank Shadwani said:
    Incorrect GEL scripts causing the data display issue, or

    The GEL files and their console outputs now match the console outputs you previously shared.

    Cortex_R5_0: GEL Output: Gel files loading Complete
Cortex_R5_0: GEL Output: ***OnTargetConnect() Launched***

Cortex_R5_0: GEL Output: AM263Px Initialization Scripts Launched. 
Please Wait...


Cortex_R5_0: GEL Output: AM263Px_Cryst_Clock_Loss_Status() Launched
Cortex_R5_0: GEL Output: Crystal Clock present 
Cortex_R5_0: GEL Output: AM263Px_SOP_Mode() Launched
Cortex_R5_0: GEL Output: SOP MODE = 0x0000000B    
Cortex_R5_0: GEL Output: Dev Boot Mode 
Cortex_R5_0: GEL Output: AM263Px_Read_Device_Type() Launched
Cortex_R5_0: GEL Output: EFuse Device Type Value = 0x000000AA    
Cortex_R5_0: GEL Output: AM263Px_dual_or_lockstep_mode() Launched
Cortex_R5_0: GEL Output: r5fss0 = 0x00000101    
Cortex_R5_0: GEL Output: r5fss1 = 0x00000100    
Cortex_R5_0: GEL Output: R5FSS0 is in Lockstep mode 
Cortex_R5_0: GEL Output: R5FSS1 is in Lockstep mode 
Cortex_R5_0: GEL Output: MSS_CTRL Control Registers Unlocked
Cortex_R5_0: GEL Output: MSS_TOP_RCM Control Registers Unlocked
Cortex_R5_0: GEL Output: MSS_RCM Control Registers Unlocked
Cortex_R5_0: GEL Output: MSS_IOMUX Control Registers Unlocked
Cortex_R5_0: GEL Output: TOP_CTRL Control Registers Unlocked
Cortex_R5_0: GEL Output: *** R5FSS0 DualCore Reset ***
Cortex_R5_0: GEL Output: *** R5FSS1 DualCore Reset ***
Cortex_R5_0: GEL Output: R5F ROM Eclipse
Cortex_R5_0: GEL Output: R5FSS0_0 Released
Cortex_R5_0: GEL Output: R5FSS0_1 Released
Cortex_R5_0: GEL Output: R5FSS1_0 Released
Cortex_R5_0: GEL Output: R5FSS1_1 Released
Cortex_R5_0: GEL Output: L2 Mem Init Complete
Cortex_R5_0: GEL Output: MailBox Mem Init Complete
Cortex_R5_0: GEL Output: r5fss0 = 0x00000001    
Cortex_R5_0: GEL Output: r5fss1 = 0x00000000    
Cortex_R5_0: GEL Output: R5FSS0 is in Dual-Core mode 
Cortex_R5_0: GEL Output: R5FSS1 is in Dual-Core mode 
Cortex_R5_0: GEL Output: CORE PLL Configuration Complete
Cortex_R5_0: GEL Output: PER PLL Configuration Complete
Cortex_R5_0: GEL Output: SYS_CLK DIVBY2
Cortex_R5_0: GEL Output: DPLL_CORE_HSDIV0_CLKOUT0 selected as CLK source for R5FSS & SYS CLKs
Cortex_R5_0: GEL Output: CLK Programmed R5F=400MHz and SYS_CLK=200MHz 
Cortex_R5_0: GEL Output: Configure all Peripheral clocks()
Cortex_R5_0: GEL Output: 

 *** Enabling Peripheral Clocks *** 
Cortex_R5_0: GEL Output: Enabling RTI[0:3] Clocks 
Cortex_R5_0: GEL Output: RTI0 Clock Enabled (200MHz)
Cortex_R5_0: GEL Output: RTI1 Clock Enabled (200MHz)
Cortex_R5_0: GEL Output: RTI2 Clock Enabled (200MHz)
Cortex_R5_0: GEL Output: RTI3 Clock Enabled (200MHz)
Cortex_R5_0: GEL Output: Enabling RTI_WDT[0:3] Clocks 
Cortex_R5_0: GEL Output: WDT0 Clock Enabled (200MHz)
Cortex_R5_0: GEL Output: WDT1 Clock Enabled (200MHz)
Cortex_R5_0: GEL Output: WDT2 Clock Enabled (200MHz)
Cortex_R5_0: GEL Output: WDT3 Clock Enabled (200MHz)
Cortex_R5_0: GEL Output: Enabling UART[0:5]/LIN[0:5] Clocks 
Cortex_R5_0: GEL Output: LIN0_UART0 Clock Enabled (160MHz)
Cortex_R5_0: GEL Output: LIN1_UART1 Clock Enabled (160MHz)
Cortex_R5_0: GEL Output: LIN2_UART2 Clock Enabled (160MHz)
Cortex_R5_0: GEL Output: LIN3_UART3 Clock Enabled (160MHz)
Cortex_R5_0: GEL Output: LIN4_UART4 Clock Enabled (160MHz)
Cortex_R5_0: GEL Output: LIN5_UART5 Clock Enabled (160MHz)
Cortex_R5_0: GEL Output: Enabling OSPI Clocks 
Cortex_R5_0: GEL Output: OSPI0 Clock Enabled (133MHz)
Cortex_R5_0: GEL Output: Enabling I2C Clocks 
Cortex_R5_0: GEL Output: I2C Clock Enabled (48MHz)
Cortex_R5_0: GEL Output: Enabling TRACE Clocks 
Cortex_R5_0: GEL Output: Trace Clock Enabled (250MHz)
Cortex_R5_0: GEL Output: Enabling MCAN[0:3] Clocks 
Cortex_R5_0: GEL Output: MCAN0 Clock Enabled (80MHz)
Cortex_R5_0: GEL Output: MCAN1 Clock Enabled (80MHz)
Cortex_R5_0: GEL Output: MCAN2 Clock Enabled (80MHz)
Cortex_R5_0: GEL Output: MCAN3 Clock Enabled (80MHz)
Cortex_R5_0: GEL Output: Enabling MMCSD Clocks 
Cortex_R5_0: GEL Output: MMCSD Clock Enabled (48MHz)
Cortex_R5_0: GEL Output: Enabling MCSPI[0:4] Clocks 
Cortex_R5_0: GEL Output: MCSPI0 Clock Enabled (48MHz)
Cortex_R5_0: GEL Output: MCSPI1 Clock Enabled (48MHz)
Cortex_R5_0: GEL Output: MCSPI2 Clock Enabled (48MHz)
Cortex_R5_0: GEL Output: MCSPI3 Clock Enabled (48MHz)
Cortex_R5_0: GEL Output: MCSPI4 Clock Enabled (48MHz)
Cortex_R5_0: GEL Output: Enabling CONTROLSS Clocks 
Cortex_R5_0: GEL Output: CONTROLSS Clock Enabled (400MHz)
Cortex_R5_0: GEL Output: Enabling CPTS Clocks 
Cortex_R5_0: GEL Output: CPTS Clock Enabled (250MHz)
Cortex_R5_0: GEL Output: Enabling RGMI[5,50,250] Clocks 
Cortex_R5_0: GEL Output: RGMII5 Clock Enabled (5MHz)
Cortex_R5_0: GEL Output: RGMII50 Clock Enabled (50MHz)
Cortex_R5_0: GEL Output: RGMII250 Clock Enabled (250MHz)
Cortex_R5_0: GEL Output: Enabling XTAL_TEMPSENSE_32K Clocks 
Cortex_R5_0: GEL Output: TEMPSENSE Clock Enabled (32KHz)
Cortex_R5_0: GEL Output: Enabling XTAL_MMC_32K Clocks 
Cortex_R5_0: GEL Output: XTAL_MMC Clock Enabled (32KHz)
Cortex_R5_0: GEL Output: 

 ***All IP Clocks are Enabled*** 

Cortex_R5_0: AM263Px
Cortex_R5_0: Board Selected : CC
Cortex_R5_0: Part Selected : Standard
Cortex_R5_0: GEL Output: CPU reset (soft reset) has been issued through GEL on program load.

    Mayank Shadwani said:
    Incorrect device ID read resulting in shuffled data?

    The device ID read is still incorrect or shuffled data. See the below image

    All the register configurations are nearly identical to those in the example project.

    Note: Does the OSPI peripheral include a built-in DMA engine? In the example code, I noticed that DMA is being configured, but in my custom implementation I disabled the DMA and its associated logic.

    According to the TRM, DMA is not supported for the OSPI peripheral; however, the SDK still performs some DMA-related configuration. I am not sure why this is the case. See image below

    I also observed that the SDK uses an interrupt in connection with the DMA. Could you explain the purpose of using the interrupt in this context?

    Thanks in advance....

  • 0 in reply to Sanith goud Kothuri
    TI__Expert 7615 points

    Hi Sanith, 

    Since the SDK code works, this can be a register configuration issue. Can you do read ID in the flash initialization routine of the custom code. Since your code is based on the OSPI - Flash driver of SDK, can you take a dump of the ospi register space just before Read ID. Then execute the SDK code till this point and again take the register dump. We can check what configurations are different in this scenario from both codes.

    Regards,

    Aswin

  • 0 in reply to Aswin Sankar
    TI__Expert 7615 points

    Hi Sanith, 

    Also is it feasible for you to check this in 1s-1s-1s mode. Please excuse me for joining in. Apologies if I missed some points.

    Regards,

    Aswin

  • 0 in reply to Aswin Sankar
    Prodigy 170 points
    Aswin Sankar said:
    Also is it feasible for you to check this in 1s-1s-1s mode. Please excuse me for joining in. Apologies if I missed some points.

    Hi  

    No problem at all, Glad to have you please jump in whenever required.

    I Tried in 1s-1s-1s mode thinks are working as expected and this API "Bootloader_parseAndLoadMultiCoreELF" is returning value zero (SystemP_SUCCESS) which is expected.

  • 0 in reply to Sanith goud Kothuri
    Prodigy 170 points

    Hi      

    I observed there is a difference in the configuration structure value initialization. What does this actually do, and how does it affect the OSPI-FLASH operation? For example, in the 'OSPI_flash_io_am263px-cc' SDK example, the Flash_DevConfig structure is initialized with .fourByteAddrEnSeq = 0xA1 and .xspiWipRdCmd = 0x00, 

    whereas in the 'sbl_ospi_multicore_elf' SDK example, the structure members are set to .fourByteAddrEnSeq = 0x0 and .xspiWipRdCmd = 0x05. How does this difference affect the OSPI-FLASH working?"

    Thanks in advance ...

  • 0 in reply to Sanith goud Kothuri
    TI__Expert 7615 points

    Hi Sanith, 

    The xSPI read status register command should be 0x05. The Read status register command is also 0x05. So this is not causing an issue or difference in the working. Let me check regarding the four byte address enable sequence and get back. 

    Regards,

    Aswin

  • 0 in reply to Aswin Sankar
    Prodigy 170 points

    Hi   

    Aswin Sankar said:
    The xSPI read status register command should be 0x05. The Read status register command is also 0x05.

    Why this is required is "SBL_OSPI_multicore" example project and why this is not required in "OSPI_flash_IO" example project?

    1) In SBL_OSPI_Multicore example project, since .xspiWipRdCmd = 0x05, if condition is the OSPI_FLASH_CFG_FLASH_CMD_CTRL_REG value is 0x059B0800.

    why address is required to read a status register.(correct me if i'm wrong, address is required only to read volatile or non volatile registers)

    2) In OSPI_FLASH_IO example project, since .xspiWipRdCmd = 0x00, same if condition failed and else if got true and executed.

    OSPI_FLASH_CFG_FLASH_CMD_CTRL_REG value is 0x05900800, here there is no 'En_CMD_ADDR_FLD' bit and 'NUM_ADDR_BYTES' filed set.

    Why this behavior to read the same status register in two different project?

     

    On what basis this did? 

  • 0 in reply to Sanith goud Kothuri
    TI__Expert 7615 points

    Hi Sanith, 

    Apologies for the delay. I am looking into this

    Regards,
    Aswin

  • 0 in reply to Sanith goud Kothuri
    TI__Expert 7615 points

    Hi Sanith,

    This seems to be a bug in the SDK example. For this flash, if you look at the 05h command from the flash datasheet it shows like this.

    This command does not require an address. Your statement is correct. The correct configuration would be to send command, then dummy cycles. This is also mentioned  in the command set summary for 05h. 

    Why it seems to be working when address is send out is that, when the ENB_COMD_ADDR_FLD is set. The controller will send out the transactions in the format

    cmd -> dummy cycles -> address instead of cmd -> dummy cycles

    But the flash when it sees the cmd itself, it will start pumping out the read back value after dummy cycles. Thus the ospi will always have the data to sample correctly even if the sampling point is not done after the correct number of dummy cycles.

    Regards,

    Aswin

  • 0 in reply to Aswin Sankar
    Prodigy 170 points
    Aswin Sankar said:

    This seems to be a bug in the SDK example. For this flash, if you look at the 05h command from the flash datasheet it shows like this.

    If this is a bug then it is okay.

    Ill follow then configuration settings as per "OSPI_FLASH_IO example project," in my custom project.

    Thanks for your valuable time

  • 0 in reply to Sanith goud Kothuri
    TI__Expert 7615 points

    I have filed a bug with the given link for internal tracking

    jira.itg.ti.com/.../MCUSDK-15080