AM2432: Request for confirmation on compatibility issues and fixes when migrating to Industrial Comms SDK v11

Hello Akihiro Tamura,

I moved to SBL expert to comment on the issues which belong to the SBL.

Later, we can move to OSPI experts.

Regards,

Anil.

Hi Akihiro Tamura ,

I checked the excel shared by you and the changes done for the SBL seems okay to me, one more suggestion is to use the SBL from MCU+SDK version 11.0 itself as you have now migrated to Industrial SDK V11, instead of still using the SBL from MCU+SDK v10. If you use the SBL from V11 then you might not need to incorporate these changes yourself as this will be taken care of in the latest SBL. Is there any reason on why you are still using older SBL?

Also, The changes mentioned by you in the excel sheet seem to be for am263/261 devices and are not applicable for am243.

Other Upgrade and compatibility information for industrial SDK are mentioned here: AM243x INDUSTRIAL COMMUNICATIONS SDK: Release Notes 11.00.00

Best Regards,

Meet.

Hi Meet,

Thank you for your support.

By the way, is it know issue? In release note, is there any description?

Customer needed to spend a lot of time to fix and hard to make sure if these modification is correct.

They might have more question after they migrate to IND_CUMMS_SDK v11.

1. Is it possible to show the list of all changes to IND_COMMS_SDK v11 and all known issue not listed in the current document？
2. In case, customer finds the new issue, should they post it on e2e?

Best Regards,

Kasai

Hello Meet Thakar ,

Thank you for your response and for reviewing the Excel file.

Is there any reason on why you are still using older SBL?

To clarify, the fixes listed in the Excel file were made after migrating to Industrial SDK v11, and were applied to the v11 SDK (not v10).
We are indeed using the Industrial SDK v11 and MCU+SDK v11. The mention of v10 in our initial message referred only to our previous setup, not the current one.

Also, The changes mentioned by you in the excel sheet seem to be for am263/261 devices and are not applicable for am243.

We understand that the changes might have originally been implemented for AM263/261 devices, as seen in the GitHub log comments.

However, in our environment using the AM243x device, we have observed the issues listed in the Excel file which were resolved only after applying the changes described in the Excel file.
The issues clearly indicate that the fixes are relevant to AM243x as well.

Could you kindly confirm:

1. Whether these fixes were intentionally excluded from AM243x, or
2. Whether the same issues are expected to occur under certain conditions on AM243x?

Best Regards,

A.Tamura.

Hi Akihiro Tamura ,

These changes are also included in am243's latest SDK, if you are using the latest version then you shouldn't face any issues.

mcupsdk-core/examples/drivers/boot/sbl_ospi/am243x-evm/r5fss0-0_nortos/main.c at next · TexasInstruments/mcupsdk-core · GitHub

mcupsdk-core/source/drivers/bootloader/bootloader.c at next · TexasInstruments/mcupsdk-core · GitHub

Best Regards,

Meet.

Hello Meet Thakar ,

Thank you for your reply and the reference links.

We have confirmed that for the issue listed as No.1 in our Excel file, the fix is indeed already applied in the latest SDK (Industrial SDK v11 / MCU+SDK v11). If the application follows the example code provided in the SDK, the issue should not occur — we fully agree with your assessment.

However, we are concerned that this change is not documented in the "Upgrade and Compatibility Information" section of the release notes below:

software-dl.ti.com/.../RELEASE_NOTES_11_00_00_PAGE.html

Since we encountered real functional regressions after upgrading to v11, we believe it should be included such compatibility-breaking or behavior-changing updates in the release documentation to assist developers in avoiding the issues.

In addition, we would appreciate your insights on the other issues described in No.2 through No.4 of the Excel file, as they remain unclear and have not yet been addressed in your previous response.

Best regards,

A.Tamura.

Hi Akihiro Tamura ,

Akihiro Tamura said:

However, we are concerned that this change is not documented in the "Upgrade and Compatibility Information" section of the release notes below:

The section only mentions changes which could affect user applications developed using older SDK version, that is why SBL changes are not mentioned.

Issue number 3 related is also already fixed as shared by me in the previous response: https://github.com/TexasInstruments/mcupsdk-core/blob/next/source/drivers/bootloader/bootloader.c#L727

I see that you have reverted back to V10 code for issue number 2 and 4 for OSPI, you ideally shouldn't face any issues, could you elaborate what issues you are facing due to this and how you were able to identify that this piece of code causes this issue, so that I can route this query to our OSPI expert and he can help your further.

Best Regards,

Meet.

Hello Meet Thakar ,

Meet Thakar said:

Issue number 3 related is also already fixed as shared by me in the previous response: https://github.com/TexasInstruments/mcupsdk-core/blob/next/source/drivers/bootloader/bootloader.c#L727

We believe you are referring to the addition of the following code in the sbl_ospi example main.c:

/* This buffer needs to be defined for OSPI boot in case of HS device for
 * image decryption and authentication
 * The size of the buffer should be large enough to accommodate the appimage
 */
uint8_t gAppimage[0x800000] __attribute__ ((section (".app"), aligned (4096)));
...
bootConfig = (Bootloader_Config *)bootHandle;
bootConfig->scratchMemPtr = gAppimage;

This change appears to be relevant only for HS devices, and unnecessary for HS-FS devices.

In our case, we are using HS-FS devices, so we would like to disable this logic. Our concerns are not only about increased memory usage, but also about the impact on boot time due to additional memory handling during the boot process.

Is there a recommended way to disable BOOTLOADER_SCRATCH_MEM_SUPPORT for HS-FS devices, either through SysConfig or compile-time flags?

Meet Thakar said:

I see that you have reverted back to V10 code for issue number 2 and 4 for OSPI, you ideally shouldn't face any issues, could you elaborate what issues you are facing due to this and how you were able to identify that this piece of code causes this issue, so that I can route this query to our OSPI expert and he can help your further.

We reverted to MCU+SDK v10 code for certain OSPI functions because the Winbond flash memory (W35T25NW) that was previously working with v10 no longer operated correctly after upgrading to v11.

We identified the problematic area by comparing the differences in OSPI-related source files between SDK v10 and v11. After restoring the v10 implementation, the flash memory resumed normal operation.

Best Regards,

A.Tamura.

Hi,

Akihiro Tamura said:

Is there a recommended way to disable BOOTLOADER_SCRATCH_MEM_SUPPORT for HS-FS devices, either through SysConfig or compile-time flags?

This is enabled using this macro in bootloader_soc.h: https://github.com/TexasInstruments/mcupsdk-core/blob/next/source/drivers/bootloader/soc/am64x_am243x/bootloader_soc.h#L45

You can remove this definition if you want to disable the scratch memory support.

Best Regards,

Meet.

Hi Meet,

I talked to Tamura-san.

[No.3] 

• Is your suggesting of removing definition equivalent to Tamura-san's change?
• Is Tamura-san's change no problem? They also need to know the reason.

[No.2 and No.4]

• V11 does not work but V10 works. What is the potential root cause?
• Is it ok to keep using V10? They also need to know the reason.

[SBL change notice]

• Meet Thakar said:

  The section only mentions changes which could affect user applications developed using older SDK version, that is why SBL changes are not mentioned.
• Is there any way to notify users for SBL change? Change of SBL is as important as change of user application.

Thank you.

Best Regards,

Kasai

Hi Kasai-San,

Akihiro Tamura said:

This change appears to be relevant only for HS devices, and unnecessary for HS-FS devices.

HS here refers to both HS-FS and HS-SE devices, this buffer is used to perform the authentication of the appimage. But if you want to disable it for your SBL for memory usage issue or any other concerns then you can disable BOOTLOADER_SCRATCH_MEM_SUPPORT it.

Tetsuro Kasai said:

[No.2 and No.4]

• V11 does not work but V10 works. What is the potential root cause?
• Is it ok to keep using V10? They also need to know the reason.

I will have to route this thread to our OSPI expert for these queries, please wait for their response.

Best Regards,

Meet.

Akihiro Tamura said:

Winbond flash memory (W35T25NW)

From OSPI context, my understanding is for the mentioned flash part, the functionality was okay in version 10 and it is not okay with version 11.

Please let me know if the customer has enough time to debug where exactly is seen.

If the customer is short on time, then please share with me the protocol used for the flash part you are using? Based on the protocol, I can check the flash's flow inside flash_nor_ospi.c -> ospi_v0.c -> ospi_v0_lld.c

Thanks,

Vaibhav

Hi Viaibhav,

Vaibhav Kumar said:

From OSPI context, my understanding is for the mentioned flash part, the functionality was okay in version 10 and it is not okay with version 11.

Yes, your understanding is correct.

Vaibhav Kumar said:

If the customer is short on time, then please share with me the protocol used for the flash part you are using? Based on the protocol, I can check the flash's flow inside flash_nor_ospi.c -> ospi_v0.c -> ospi_v0_lld.c

I'll check the details with customer. What I know is 8d-8d-8d. If you need more information, could you let us know?

Best Regards,

Kasai

Hi,

Tetsuro Kasai said:

What I know is 8d-8d-8d. If you need more information, could you let us know?

As per your assumption I am going to compare MCU SDK 10.x with 11.x and look out for 8D protocol changes in the drivers(if there are any).

Thanks,

Vaibhav

Hi,

I see lld introduction in the drivers, but the source/board does remain the same in terms of file hierarchy.

Vaibhav Kumar said:

Please let me know if the customer has enough time to debug where exactly is seen.

Although I have seen the excel sheet, please share the failure logs seen at customer's setup.

Best,

Vaibhav

Hi Vaibhav,

I added explanation of what they concerned. Can you check the below?

No. 2 and 4   OSPI Flash 8d-8d-8d failure

No.3 Build error when BOOTLOADER_SCRATCH_MEM_SUPPORT is defined

Best Regards,

Kasai

Hi,

Tetsuro Kasai said:

No.3 Build error when BOOTLOADER_SCRATCH_MEM_SUPPORT is defined

There is a better way to disable scratch memory usage for a particular bootloader instance, please refer to this thread: 

 RE: MCU-PLUS-SDK-AM243X: Disable Bootloader scratch memory - BOOTLOADER_SCRATCH_MEM_ENABLE define 

Best Regards,
Meet.

Hi Tetsuro,

Thanks for waiting.

For the two changes you have shared: cmdAddr = 0 should work for you as the flash that the customer is using, must have the cmdAddr required to be 0 and not any other value while reading the device id and manufacture id. Please share the flash datasheet for me to confirm this.

For the OSPI_lld_enableDdrRdCmds, it is setting the bit for DDR rd cmds to 1. I have tracked the changes and the owner for the same. Once the owner is back from sick leave, I will update you with the intention behind the change and if it can be avoided for the flash you are using.

For the second point you mentioned, Meet has responded with a thread link. Please have a read through it.

Thanks,

Vaibhav

Hi Vaibhav, Meet,

Thank you for your update.

[No.2]

Vaibhav Kumar said:

Please share the flash datasheet for me to confirm this.

https://www.winbond.com/hq/support/documentation/downloadV2022.jsp?__locale=ja&xmlPath=/support/resources/.content/item/DA00-W35T25NW.html&level=1  

The important thing is to know the reason why the code was changed from V10 to V11?  It looks like cmdAddr = 0 in V10 and cmdAddr ≠ in V11.

[No.3]

Thank you for the link. Will talk to customer.

Best Regards,

Kasai

Hi Kasai,

For your flash, I referred the section for reading jedec id via 9Fh command.

The snippet of that is shown here:

Please tell me the value of idCfg->dummy8 which is used inside Flash_norOspiReadId, assuming your mode of operation as 8d-8d-8d?

Thanks,

Vaibhav

Hi Vaibhav Kumar ,

Vaibhav Kumar said:

Please tell me the value of idCfg->dummy8 which is used inside Flash_norOspiReadId, assuming your mode of operation as 8d-8d-8d?

The value of dummy8 is "8".

Best regards,

A.Tamura

Hi,

So in the SDK 10 vs SDK 11 the following difference is there:

So you are saying that code is reverted back to SDK 10, to resolve the issue.

This would mean that cmdAddr = OSPI_CMD_INVALID_ADDR in SDK 10

And

cmdAddr = 0 in SDK 11

Based on your explanation in the excel sheet, when cmdAddr  = 0 then it is successful.

That would mean SDK 11 is good for you right? and not SDK 10.

Attaching the relevant screenshot you wrote in excel.

Please clarify the above.

Thanks,

Vaibhav

Hi Vaibhav,

Sorry for taking time.

I checked with customer.

In their settings, dummy8 is "8" and cmdAddr should not be 0.

In V11, cmdAddr becomes 0, no matter what dummy8 is.

In V10, cmdAddr is not 0, when dummay8 is "8".  This is what customer want to do. So, they changed the v11 based code to v10.

Here is the question.

[Question]

Wny "if(idconfig->dummy8 !=0{" was remove in V11 although V10 had. 

Why 

Hi,

Thanks for clarifying.

I will get back to you in a business day.

Thanks,

Vaibhav

Hi Vaibhav,

Did you get any feedback?

Best Regards,

Kasai

Hi,

I am actively reviewing this and will provide feedback in sometime.

Thanks,

Vaibhav

Hi Tetsuro,

I believe there is a Macronix flash MX25UW64 on the AM261x-LP TI EVM. In Octal Mode, this flash(requires 8 dummy cycles in octal mode) and cmdAddr value of 0. Hence, the SDK update/commit was made in such a way to accommodate one of many such flashes on the AM2X EVMs.

I understand this is breaking the customer's flash logic, as they require cmdAddr to be invalid in order to read the device and manufacture id.

Currently this tweak is okay for the customer to make, as the flash they are using is currently not tested on one of our TI EVMs. I also understand that the driver should be generic to all flashes out there. But, in this case, since we have not tested out with Winbond flash(due to it not being on the AM2X TI EVM) we see this driver update in Flash_norOspiReadId.

I will check with the SW team to narrow down this reading procedure in such a way that it is generic to most flashes.

Thanks,

Vaibhav

Hi Vaibhav,

Thank you for your reply.

Vaibhav Kumar said:

Currently this tweak is okay for the customer to make, as the flash they are using is currently not tested on one of our TI EVMs.

Is the understanding as below correct?

So, as a conclusion, customer change of OSPI driver is appropriate.

TI will consider improving the OSPI driver to be more generic.

Best Regards,

Kasai