TMDS64EVM: IND-COMMS SDK 9.2.0.7 Profinet Demo

Hi Philip,

Could you let me know if you are using AM64x GP or HSFS EVM? Also what is the board version? Board version begins with "PROC101".
Currently we have observed some issues with GP EVM. Could you please test with AM64x HS-FS EVM once and let us know?

Best Regards,
Laxman

Hi Laxman,

thank you for the response. 

The borad is a HSFS, this is the output of the Uart Parser:

The board version is PROC101C(004)

Best Regards
Philip

Hi Philip,

This example should work out of the box, no additional steps are required here. Could you please share the application image which you are using? We will test this at our side and check the behavior once.

Best Regards,
Laxman  

Hi Laxman,

thank you for your support. Please find the out-file attached to this post.

Best Regards
Philip

Edit: It seems like the forum does not allow me to upload the file. There is an upload dialog, but after it completes nothing happens. Is there another way I can forward you the file? 

Hi Philip,

You can use this drive link to upload the .out file here.

Drive link: https://tidrive.ext.ti.com/u/8PUOREL1DlLi9Q5d/50e4fb0d-574d-406b-9d87-f996da1baccb?l
Passcode: H)vc66rJ

Regards,
Laxman

Hi Laxman, 

thank you for the Link, I uploaded the output of the example build.

Best Regards
Philip

Hi Philip,

Thank you for uploading, will test this and get back to you.

Best Regards,
Laxman

Hi Philip,

I have tested the .out file you have shared in the drive link and it seems to be working fine and also the UART console prints the complete stack initialization logs.
One more reason that could cause the difference in behavior would be the device part number. Could you manually check on the AM64x central chip and send the complete device details.  Please refer the below image for context. The below image part number which we have used to test is:

XAM6442B
SFGHAALV

Currently all the stacks only work if the feature "F" (bold letter in part number) is present in the device. Please refer the features in 9.1.2 section of the below document for details.
https://www.ti.com/lit/ds/symlink/am6442.pdf?ts=1717741095159&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FAM6442

Best Regards,
Laxman

Hi Laxman,

thank you for the feedback. I checked and the print on my chip is the same:
XAM6442B
SFGHAALV
24P21XS.

For reference, the steps I'm doing to run the example are:

1) Connect USB cables to onboard UART and JTAG interfaces
2) Flash SOC Initialization Binary according to SDK docu.

After switching from UART to OSPI boot mode, the terminal output is as expected according to the docu:

3) Import profinet example project from Industrial Communications SDK for AM64x 9.2.0.07 into new CCS workspace.
4) In CCS project properties the products SysConfig 1.20.0 and Industrial Communications SDK for AM64x 9.2.0.07 are present, no others
5) Build Project in release config according to "Using SDK with CCS Projects" docu page
6) Start the launch configuration included with the project according to docu section "CCS Launch, Load and Run"
7) In the then started debug session, connect to target R5_0_0
8) Reset the connected CPU
9) Load previously compiled binary to connected CPU -> Halts at entry of main()
10) Resume leads to following terminal output:

I also tried with the 1-Click debug steps described in the docu as well as initialization through SD Boot mode, both leading to the same result.

Would this be the correct procedure? Maybe you could provide me with the steps/setup you used to get the out-file I uploaded to run? 

Another thing I tried is integrating the new stack into our RpMsg application that is loaded via Linux remoteProc to the R5. I can see that the R5 application is communicating via RpMsg with the Linux application and receives its initial configuration. When starting the stack it gets stuck with the same result as described above with the example.

Please let me know if I can provide any other infos.

Edit: This here seems to be the location where the stack enters an endless loop while waiting for the PNPB_State to change:

Best Regards
Philip

Hi Philip,

I have looped in our stack team to answer any further queries as the issue seems to be related to stack initialization. They will provide a response soon on this topic.

Best Regards,
Laxman 

Hi Philip,

before getting deeper into this topic, I would like us to try OSPI bootloader rather than NULL bootloader. I will explain how to do this in the following steps:
- Set the board switches to UART boot mode
- Connect UART to your PC and remember the number of the new COM port that appears on your device manager window (usually the smallest in the list)
- Open the file: <SDK PATH>\mcu_plus_sdk\tools\boot\sbl_prebuilt\am64x-evm\default_sbl_ospi
- Comment out line 24 (we don't need to send a new bootloader)
- In line 27: set the "file" parameter to the path and file name of the app image file generated using CCS (the one with ".appimage.hs_fs" extension). It's easier to copy the file from CCS workspace to the SDK in order to make the relevant path to the file shorter.
- Go to: <SDK PATH>\mcu_plus_sdk\tools\boot and run the following command: python.exe uart_uniflash.py -p COM<PORT NUMBER> --cfg=sbl_prebuilt/am64x-evm/default_sbl_ospi.cfg

If the flashing process was successful:
- Set the board switches to OSPI boot mode

then try to switch the device off then on again and send us please a new screenshot for the terminal output.

Kind regards,
Kamil

Hi Kamil,

since in my case the NULL-bootloader was still programmed, I had to keep line 24 in the .cfg-file, at least for the first execution of uart_uniflash.py. I also commented out the line for the XIP file, if I understand it correct it is not needed for this case?

Flashing worked, please find the terminal output of the startup in OSPI bootmode in the following screenshot

Best Regards
Philip

Hi Philip,

thanks for your response. I was able to see the problem on one of our devices yesterday. We will take a deeper look into it and get back to you as soon as possible.

Kind regards,
Kamil

Hi,

We're seeing the same issue (same software, same hardware, stuck at the same location). Has there been any progress?

Regards,

Dominic

Small update:

we tried with a different board (same version, prcocessor with similar markings but e.g. other lot), and that worked.

Regards,

Dominic

Hi Dominic and Philip,

We have been running tests and have found out that there are few causes for the application getting stuck. We have currently fixed one issue and are looking to completely resolve this issue. We are working on this on priority and will provide an update on this soon. 

Thank you for your patience.
Laxman

Hi Laxman,

thank you for the update, I tested the binary with my EVM and it does look good:

I could set it up with a PLC and a connection is established.
Thank you for resolving the issue and we are looking forward to receiving the fixed version.

Kind regards
Philip