MCU-PLUS-SDK-AM263PX: SBL OSPI issues in version 11

Nathan Ostrye said:

1) The sbl_ospi folder is empty. Did this example just go away in favor of some other example? its odd that the folder still exists, but is empty.

Hi Nathan,

This is in accordance with our discussion where I had mentioned that rprc(.appimage) image format support(SBL, build infra) will be removed.

Please use SBL_OSPI_mcelf for further testing.

I think you are already using it.

Nathan Ostrye said:

2) Not all of the SBL OSPI examples got their OSPI pins assigned. Looking at the sbl_ospi_fastboot/am263px-cc example.syscfg, it is clearly setup to suggestSolution (resolves to "Any" within syscfg) for all the pins on the OSPI.

I will get this fixed, i am also bit shocked if this got missed by the team, apologies for this one.

Nathan Ostrye said:

3) The sbl_ospi_multicore_elf/am263px-cc example.syscfg has ALMOST all the ospi pins assigned. The RESET_OUT0 is still configured to suggestSolution of EPWM11_B. When built, this project (and the previous sbl_ospi from sdk 10_02_00_15, and the sdk 11_00_00_00_19 sbl_ospi_fastbook/am263px-cc) the RESET_OUT0 pin resolves to EPWM11_B (seen in the pinmux.csv as well as the ti_pinmux_config.c).According to the schematic (and verified through code we've developed), this pin on the am263px-cc is actually connected to the USER_LED1, and only the USER_LED1. Within this project is a very specific flashFixUpOspiBoot() function which calls The OSPI_setResetPinStatus() function to set the pin high then low. Although its hard to tell if those reset functions actually get called with our version of the control card (they appear to get skipped).

This needs to be adapted according to your board. We have suggestions for flash reset(flashfixUp apis) in SDK, it would be up to you to ensure that a proper flash reset mechanism is present at the board level and at the application level.

Based on one of the hardware issues we discovered, a modification was made to reset mechanism.

Nathan Ostrye said:

There still does not seem to be a truly valid example solution in the latest SDK.

Hi Nathan,

As stated during the discussion, it has not yet been concluded that the issue is with the SBL SDK, as other customers who are implementing it in a similar way have not reported such issues. I would recommend first root causing on your setup where it crashes and goes into faliure.

Can you share your SBL project, so that I can also observe the stability concerns you are seeing.

The current issue is that we are not switching into 4-byte mode some of the time. I have one control card that works fine 80% of the time, and another control card (same revision) that never boots even when both are running the exact same image from boot. before I post specifics, I would like to make it clear that this is just the most recent issue we are facing as we continue to play whack-a-mole with seemingly random issues.

We can see that when then board boots as expected, we are able to connect to R5_0 and read memory region 0x600E0000 and see:

On the board that never boots correctly, when we view memory region 0x600E0000, we can clearly see that we are only getting 3 of 4 bytes:

We have validated all switch settings. and we have used UniFlash to validate that the contents at address 0x600E0000 appear as expected after programming (all 4 bytes present from both control cards).

When I add in the loop_forever function to the SBL then connect in CCS to step through the boot on the failing control card, I see the following:

Please note that we have slowly rolled back modifications to TI's example code in an effort to stabilize things. The functions called throughout this pictured main code have not been modified from the sbl_ospi example from SDK 10_02_00_15.

Hi Nathan,

One point I wanted to clarify,

Do you take care of flashing the PHY attack vectors which are important if you are running OSPI at max frequency. SOme OSPI instability could be caused because of that?

The project files have been uploaded to the TI Drive, so feel free to double check the settings. however, as far as I can see, the PHY configuration in our SBL project is exactly the same as what is in the sbl_ospi example from SDK 10_02_00_15.

A very interesting observation. While using the consistently failing control card, I loaded the unaltered build from the sbl_ospi example with loop_forever enabled and walked through the main function until I reached the Bootloader_profileAddProfilePoint("Board_driversOpen") call. In this instance, I did not get any indication that the PHY had failed to initialized (as shown above in this thread).

After that, I re-loaded our custom SBL onto that same control card and walked through the code to that same point in code. This time, I did not receive the error regarding failure to correctly enable the PHY. I am also now able to see the contents of memory address 0x600E0000 correctly (all 4 bytes instead of 3). 

So, I believe may be onto something with the PHY not being started correctly. However, I have not been able to determine where in SysConfig or custom code where there is a difference on the PHY from our custom SBL to the sbl_ospi example.

Yes that is possible as you need to program the attack vector at 0x80000 offset atleast once, as long as it is present and not erased, PHY tuning will work as expected with other programs also.

are you able to provide me with additional details on what you mean by "program the attack vector at 0x80000 offset"? is there something in the technical reference manual or a procedure somewhere that has details on what this is and how to do it correctly?

What is PHY tuning and attack vectors: https://www.ti.com/lit/pdf/spract2

More details here: e2e.ti.com/.../faq-am62x-am62ax-am62px-am62d-q1-am64x-am243x-ospi-phy-tuning-algorithm