AM2434: SFPD Flash Driver Support in AM243x MCU+ SDK08.06.00.43

Hi AndreTseng,

The SFDP values, configuration by the driver might be working on different SFDP versions. This is the reason why we created an FAQ to support manually adding and understanding these configurations while doing so.

Link to the FAQ - https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1230063/faq-mcu-plus-sdk-am243x-faq-how-to-debug-develop-migrate-the-flash-driver-for-custom-flash-on-non-ti-evm-ospi-xspi

This will enable your flash in one of the fastest ways, without you having any dependency over TI support.

Hope it helps.

Best Regards,
Aakash

1.  So how do I know which version of SPFD is workable?

2. The default flash S28HS512T does support SPFD, why the method in your FAQ doesn't work on EVM??

3. Any workable SPFD driver can be demo by EVM or Launchpad?

Regards

Andre 

Hi AndreTseng,

Please find the details here - https://software-dl.ti.com/mcu-plus-sdk/esd/AM243X/latest/exports/docs/api_guide_am243x/CUSTOM_FLASH_SUPPORT_GUIDE.html

1. Working at very high operating frequency, the dummy cycles even though suggested by datasheet might not work. Hence by experimentation, this is devised which value will be the apt.

2. Its not it does not work with SFDP of EVM. The thing is that these information is best taken from datasheet. The CMDs of read and write will be part of SFDP table but "bit level information" might not be presented. But rest all of the data which is filled, is mostly correct and according to the spec.

So datasheet is the best place to revert back if things stops working because of these configurations.

The FAQ is written in the simplest ways, where users exactly knows what are the changes that are being done.

Best Regards,
Aakash

Askash,

   Would you mind to close the issue after both of us agree issue is solved?

I still have a lot questions need to provide answer to customers :

1. On which EVM, we load json git from opsi_flash_diag demo work directly without modification?? How do we verify this function is workable?

2. In the report of ospi_flash_diag: The "bitP" :11  is binary 0b11 or decimal 11?

"dummyCfg": {
"isAddrReg": true,
"cmdRegRd":"0x65",
"cmdRegWr":"0x71",
"cfgReg":"0x00800003",
"shift":0,
"mask":"0x03",
"bitP":11

if this value is decimal 11 / 0b1011 Dummy cycle is set to 24.

Looks like default setting 25 is conflict then register setting.

And mask value in json is 0x00, is wrong. 

"protoCfg": {
"isAddrReg": true,
"cmdRegRd": "0x65",
"cmdRegWr": "0x71",
"cfgReg": "0x00800006",
"shift": 0,
"mask": "0x00",
"bitP": 0
},
"strDtrCfg": {
"isAddrReg": true,
"cmdRegRd": "0x65",
"cmdRegWr": "0x71",
"cfgReg": "0x00800006",
"shift": 1,
"mask": "0x00",
"bitP": 1
} 

How can we trust result from ospi_flash_diag? 

Regards

Andre

I also want to know where this 133MHZ coming from

According to TRM, OSPI_RCLK coming from MAIN_PLL0_HSDIV1_CLKOUT or MAIN_PLL1_HSDIV5.

They should be 200MHz and 160MHz.

So where is this 133MHz coming from?

Regards

Andre

Hi Andre,

In K3 architecture, the clocks are enabled and configured via TISCI services -

• More details in the documentation of TISCI - http://downloads.ti.com/tisci/esd/latest/2_tisci_msgs/pm/clocks.html#pm-clocks-msg-set-clock
• SDK file - SOC_moduleSetClockFrequency in soc.c is invoking Sciclient_pmGetModuleClkNumParent and Sciclient_pmModuleClkRequest in sciclient_pm.c
• ti_power_clock_config.c file contains the information created via SYSCFG.

Do you need more details ? The clocking is very abstracted and handled directly via TISCI.

Best Regards,
Aakash

Yes, I do need know exactly where this 133MHz coming from. Even using the TISCI to request and configuration, chip hardware still have its coming source. 

like MAIN_PLL0_HSDIV1 is coming from 2000Mhz and divide 10 So it is 200Mhz.  Unless the TRM manual is wrong or TISCI configuration just don't follow the TRM and set different value. 

I didn't get answer why SFPD report from ospi_flash_diag demo project doesn't work. What platform we can verify the load SFPD json works?

 Can you please provide  answer?

Regards

Andre

Yes, I do need know exactly where this 133MHz coming from. Even using the TISCI to request and configuration, chip hardware still have its coming source. 

like MAIN_PLL0_HSDIV1 is coming from 2000Mhz and divide 10 So it is 200Mhz.  Unless the TRM manual is wrong or TISCI configuration just doesn't follow the TRM and set different value. 

I didn't get answer why SFPD report from ospi_flash_diag demo project doesn't work. What platform we can verify the load SFPD json works?

 Can you please provide  answer?

Regards

Andre

From TRM I got answer the 133MHz coming from. 

Please provide the answer which workable platform we use for "SFPD autoload from json" verification. 

Regards

Andre 

No response?

Hi Andre,

Since you're now clear about the clocking spec, I will explain about the JSON load feature.

The backend of JSON load button in sysconfig is just a JSON parser. Whatever JSON file is given, the backend will update the configurables based on the values read from the file. So it boils down to the JSON file. Now for generating this file, we have the example application / tool called the ospi_flash_diag. The diag uses SFDP (Serial Flash Discoverable Parameters) feature of the flashes to get data about the flash. Now SFDP is not the most standardized of tables. When it comes to NOR/NAND flashes there might be a lot of vendor specific idiosyncrasies. This is why supporting custom flashes become a challenge. 

To your question as to why the S28HS512T.json which the flash diag generates is different from what you see, like I said now and mentioned in the custom flash guide, some things like dummy cycles and write delays will need one more level of tweaking. We want the OOB configuration to work, that's why we give the working configuration.

If you're using the default flash, may I know why you want to go through the custom flash support procedure when there is OOB support already?

Regards,
Anand Mahadevan SS

Anand,

    Thanks for your reply. 

1. Why customer use EVM to verify customer flash support procedure: 

     Before customer start to customize their own design, of course they want to check if the function provided by TI is work. The default FLASH supports SFPD. They do think we implement this support feature on our EVM. Check if it works then select other SPFD supported FLASH base on price or their need which can minimize their porting effort.  It's a reasonable procedure. I don't think this is strange requirement. If json load can't work on TI EVM, if you are customer, will you accept it?   

2. From SFPD reports and Flash datasheet, the read dummy cycles for 8D-8D-8D protocol is 24. The default setting uses 25. I can't explain why on our device, we can't follow the FLASH datasheet and need to use try and error experience. Is FLASH datasheet has issue? or OSPI controller wrong?

May I have your comment? 

3. More questions I can't explain to customer:

a. In TRM, we have a block diagram for read capture. We can't find OSPI_ICLK this pin, we guess this pin is OSPI_LOOPLBCLKO. Can you please confirm?

b.  We also want  to check the scheme of read capture by taps on EVM by disable PHY mode.

        We modify ospi_flash_io_am243x-evm_r5fss0-0_nortos_ti-arm-clang syscfg so that input clock source is 100MHz and divider is 4. 

        Base on calculation, OSPIO_CLK is 25MHz. And demo code runs well on EVM.

        However, we change the OSPI_RCLK to 200Mhz and divider is 8. The test result is failed. We look into flash_nor_ospi.c, we found the issue happens on  Flash_norOspiReadId(). The read data is not correct.  That surprise us. So we do some more test.  first we modify readDataCapDelay from 4  to 15 in Flash_norOspiOpen(). Recompiled driverlib, and try different combination. 

Here is the table to show the result:

From the result, we know external OSPI clock can work with 100MHz with divider set to 4. However, if we choice divider other than 4, none of them works. We can not figure out what the problem coming from. All of them fail in read chip id.

Even OSPI_OCLK is 25MHz, we can't tell why RCLK=100MHz/Divider=4 works but RCLK=200MHz/Divider=8 doesn't. What make them different?

2. Why there are two factor can inference the capture point, SMAPLE_EDGE_SEL_FLD and  DELAY_FLD in OPSI _RD_DATA_CAPTURE_REG

Question, why we only adjust DELAY_FLD only in our driver?

c. In the block diagram, If we enable PHY, it looks like RX data from external won't pass through to taps/sample edge select block diagram.

But in source code,  ospi_phy.c OSPI_phySetRdDelayTxRxDLL(), we set both of these two bit fields in PHY tuning procedure. Customer requests we provide correct information. They don't think the TRM is correct.

All of these questions I can't answer. And it is easy to reproduce on AM2434 EVM. Can you please help?

Regards

Andre

Anand

3b. Unfortunately, all the combination of RD capture delay, RCLK and Divider are not work if DIVIDER !=4 on EVM. Customer request more clear information for reading capture. the timing relationship between SPI MODE, read capture edge, and read capture delay. 

4a. Please provide correct block diagram to show how to loopback  from PHY module.

Basically, the wrong block diagram make a lot of trouble to field team, Please help to provide correct one.

The target to them is not just a workable driver. They want to push performance more so they need to understand very clearly.

Regards

Andre

Hi Andre,

Let me check with some more experts and come back on this. I will try to get some references on the spec which I explained.

Regards,
Anand M

Anand,

   Any update?

Regards

Andre

Hi Andre,

I need some more time to check on this, there are some discrepancies in the spec. But I think meanwhile they can start the development with the current available driver, we have tested it for maximum performance, at 200 MHz with PHY and DMA enabled.

Regards,
Anand Mahadevan SS