MCU-PLUS-SDK-AM243X: Questions about OSPI ineffective 8D mode

Hi,

I want to understand your setup.

It is either:

1. A custom board with AM243 SoC having OSPI flash part S28HS512T.
2. Or a AM243 TI EVM having an OSPI flash part like S28HS512T.

liang luo said:

# 4. Unsupport high frequency. Modify OSPI frequency higher than 50Mhz such as 100MHz(200MHz/2) and enable PHY mode, project can't work. PHY mode and high frequency unsupport right now and is there a plan for when to support?

Could you go ahead and try the combination of 166 MHz clock frequency and clock divider value of 4 and then enable PHY mode. Please let me know if it works with the combination I have suggested.

liang luo said:

#2. Every communication, although only read 1 byte, actually triggers 10 bytes CLK.

I need to understand what this means, I am assuming so it could be either of the following two cases:

Suppose Source Offset values in 8 bit unsigned int format is as follows: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, .......

1. First case could be that you want to read 1 byte, which is the value 1, but you end up seeing the values 1, 2, 3, 4,..., 10 on the waveform.
2. Second case could be that you want to read 1 byte, which is the value 1, but you end up seeing the value 1 read 10 times on the waveform. 

liang luo said:

#1. Read x consecutive bytes, will trigger x times transfer instead of 1 time

I am assuming you are performing a direct read operation as you are using a NOR Flash part. If yes, then for transfers of size > 1 KB DMA is used, else for transfer less than 1 KB, lets suppose for 32 bytes, you are seeing the 32 bytes getting transferred 32 times instead of 1 time on the waveform?

Looking forward to your response.

Regards,
Vaibhav

Vaibhav Kumar said:

• A custom board with AM243 SoC having OSPI flash part S28HS512T.
• Or a AM243 TI EVM having an OSPI flash part like S28HS512T.

Both, our custom board ospi flash is S28HL512T(3.3V), and we alse tested on EVM board S28HS512T(1.8V)

Vaibhav Kumar said:

Could you go ahead and try the combination of 166 MHz clock frequency and clock divider value of 4 and then enable PHY mode. Please let me know if it works with the combination I have suggested.

166MHz with div4 =41.5MHz  < 50MHz,  can work. Enable PHY mode not work, initinal failed.

Vaibhav Kumar said:

Suppose Source Offset values in 8 bit unsigned int format is as follows: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, .......

1. First case could be that you want to read 1 byte, which is the value 1, but you end up seeing the values 1, 2, 3, 4,..., 10 on the waveform.
2. Second case could be that you want to read 1 byte, which is the value 1, but you end up seeing the value 1 read 10 times on the waveform. 

First case.

Vaibhav Kumar said:

I am assuming you are performing a direct read operation as you are using a NOR Flash part. If yes, then for transfers of size > 1 KB DMA is used, else for transfer less than 1 KB, lets suppose for 32 bytes, you are seeing the 32 bytes getting transferred 32 times instead of 1 time on the waveform?

Yes,  debug and found it't just  a memcpy(). And seeing 32 times transferred for 32 bytes.

And I've run into a new question:

Import "Hello world" from SDK10, enable flash in sysconfig, Flash_read() 64 bytes failed, EVM board debug log as show the in below picture, while SDK9 is OK. How to fix this?

Example Code(hello_world.c):

#include <stdio.h>
#include <kernel/dpl/DebugP.h>
#include "ti_drivers_config.h"
#include "ti_drivers_open_close.h"
#include "ti_board_open_close.h"

#include "FreeRTOS.h"
#include "task.h"
#include <string.h>


static uint8_t buff[1<<12] __attribute__((aligned(128U)));
void ospi_waveform_test(void)
{
    uint32_t addr = 0;
    uint32_t length = 0;


    for (;;)
    {
        for (int i = 0; i <= 12; i++)
        {
            memset(buff, 0x00, sizeof(buff));

            length = (1UL << i);

            Flash_read(gFlashHandle[CONFIG_FLASH0], addr, buff, length);

            DebugP_log("\r\n[0x%X,%d]:\t %02X %02X %02X %02X\r\n", addr, length, buff[0], buff[1], buff[2], buff[3]);

            vTaskDelay(2000/portTICK_PERIOD_MS);
        }

        addr = 0x80000 - addr;

    }
}


void hello_world_main(void *args)
{
    /* Open drivers to open the UART driver for console */
    Drivers_open();
    Board_driversOpen();

    DebugP_log("Hello World!\r\n");

    ospi_waveform_test();

    Board_driversClose();
    Drivers_close();
}

Hi Vaibhav,

#1. For the PHY mode, does it need to flash PHY pattern to flash as Linux SDK mentioned?

https://software-dl.ti.com/processor-sdk-linux/esd/AM64X/10_01_10_04/exports/docs/linux/Foundational_Components/U-Boot/UG-QSPI.html

Phy Calibration

Phy Calibration allows for higher read performance. To enable phy, the phy calibration pattern must be flashed to OSPI at the start of the last erase sector. For the Cypress S28HS512T flash, this lies at the address 0x3FC0000. The partition name should be ‘ospi.phypattern’ as the driver looks for it before PHY Calibration.

Download the binary file containing the phy pattern from here. The commands below can be used to flash the phy pattern, with the location of the pattern depending on which flash is being used:

#2. Is PHY mode test on EVM board with which MCU SDK?

Hi Tony and Liang,

Please take out sometime to read through the following two FAQs.

FAQ 1(read time of 18 minutes): https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1431856/faq-am62a7-ospi-phy-tuning-algorithm

FAQ 2(read time of 5 minutes): https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1459826/faq-sk-am64b-what-is-the-purpose-of---operation-flash-phy-tuning-data

According to the code which you sent:

Flash_read(gFlashHandle[CONFIG_FLASH0], addr, buff, length);

If I am not wrong, then you want to simply, read 64 bytes from the flash offset: 0x00.

Let me try this at my end and I will update you in sometime.

Regards,

Vaibhav

Hi,

I tired reading 4096 bytes starting from 0x00. I used the top level API Flash_read(). It worked for me and I was able to read the value. Note the value at offset 0x0 from flash will be essentially the first few bytes of the Bootloader image.

Regards,

Vaibhav

Vaibhav Kumar said:

I tired reading 4096 bytes starting from 0x00. I used the top level API Flash_read(). It worked for me and I was able to read the value.

I tested the upper code on sdk9, and on sdk10 sbl_ospi, both work, but on SDK10 application level it don't work, what could possibly be the cause?

And on sbl_ospi with 166MHz  and phy enable, I can capture a 166MHz CLK, so I think phy mode is supported. But on application level phy mode abnormal.

Hi Liang,

My comments below are from application level perspective.

liang luo said:

but on SDK10 application level it don't work, what could possibly be the cause?

The flash read fails or the flash initialization fails? If you can narrow this down it would be helpful. Can you confirm which of the following is true:

1. First possibility: Can you check if flow is coming back from the Board_driversOpen() API call? Or it is stuck there itself and flash init fails.
2. Second possibility: The flow comes back from Board_driversOpen(), but you end up not being able to read the contents from flash using Flash_read().

Also, please look at the following supported combinations:

Regards,
Vaibhav

Vaibhav Kumar said:

The flash read fails or the flash initialization fails?

Debug and found than crashed when calling memcpy with 64 bytes, log show at here:

liang luo said:

Import "Hello world" from SDK10, enable flash in sysconfig, Flash_read() 64 bytes failed, EVM board debug log as show the in below picture, while SDK9 is OK. How to fix this?

liang luo said:

Import "Hello world" from SDK10, enable flash in sysconfig, Flash_read() 64 bytes failed, EVM board debug log as show the in below picture, while SDK9 is OK. How to fix this?

If enable DMA:

else:

Hi Vaibhav,  I found that it can work if delete Flash config in "MPU Armv7" (CONFIG_MPU_REGION4), include ospi phy mode and read 64 bytes. What's the basis?

liang luo said:

I found that it can work if delete Flash config in "MPU Armv7" (CONFIG_MPU_REGION4), include ospi phy mode and read 64 bytes. What's the basis?

Can you still read if you remove config_mpu_region4 and do not enable phy mode?

Vaibhav Kumar said:

Can you still read if you remove config_mpu_region4 and do not enable phy mode?

Yes

So just removing this configuration helps.

Well, by default when you open one of the OSPI applications which comes with the SDK we see that this region config_mpu_region4 is not defined, so that speaks for itself. But as a safe measure I will try to include this region in my working example and check if it fails for me as well. If it fails, I can gather some explanation and let you know.

Thank you for your patience.

Regards,

Vaibhav

OK, looking forward your update.