RTOS/PRU-ICSS-INDUSTRIAL-SW: Binary image for EtherCAT Slave

The EtherCAT team have been notified. They will respond here.

Hi David,
I am able to generate the "_ti.bin" file but it is not working. The same folder has the ".out" application generated and it is working fine if I run using the debugger.
The "_ti.bin" is loaded to flash using the SPI flasher tool. I have also connected the UART for debug logs and I can bootloader logs. It prints "Jumping to StarterWare Application..." and then I dont see any logs from application. Also the Ethercat device is not detected by TwinCAT, so it means that the ethercat application is not running if I try to run from Flash.

regards
Mohit

Hello Rahul,
Its a custom board that uses AM335x processor. I am using the bootloader from Processor SDK RTOS.
Yes I have both the files in "_ti.bin" format and app is flashed to offset 0x20000 on the SPI flash. I loaded the secondary bootloader but it is not hanging any where.
If we follow the code flow of bootloader in sbl_main.c. So it runs till the following point and then nothing happens.

/* Giving control to the application */
pfnSBLAppEntry = (void (*)(void)) gSblEntryPoint;
(*pfnSBLAppEntry)( );

The pdk version is pdk_am335x_1_0_5.

Here is the complete log seen on UART console:

StarterWare Boot Loader
BOARDInit status [0x0]
SoC : [AM335X]
Core : [A8]
Board Detected : [ICE Ver 2]
Base Board Revision : [UNKNOWN]
Daughter Card Revision: [UNKNOWN]
GPIO Instance number: 0
Pin number: 18
MCSPI Instance number: 0
Channel/Chip Select number: 0
The instance address is 48030000

Copying Header of the image
Copying image from flash to DDR
Jumping to StarterWare Application...



regards
Mohit

Mohit,

A couple of questions:

1. Have you tried booting any other simpler application like a LED blink example on your custom board using the bootloader. We need to understand if this limitted to the ethercat slave application.

2. Have you modified the board library to account for the DDR, clock and pinmux changes before testing the bootloader? 

Please provide the version number of the Processor SDK RTOS and PRU-ICSS FW so that we can check for known issues or try to reporduce this at our end. after the bootloader copies the app can you check that the binary is loaded in the expected location in DDR ? you can load symbols  from the .out by (run- Load Program -> Load Symbols) in CCS to see if the binary was loaded correctly and if the main is at the correct location.

Also, it may be useful, if you can share the bootloader and app and out binaries so that we can reproduce the issue.

Regards,

Rahul 

Hi Rahul,
I tried debugging using step-by-step execution and found that the SPI read by bootloader was not working as the variables for imageHdr were not getting updated. I checked the pinmux and compared with the official pinmux file. I found that there were some differences for MCSPI pin configurations (PIN_RX_ACTIVE, PIN_PULL_UD_EN, PIN_PULL_TYPE_SEL). So I updated this portion to use the same pin configuration as in the PDK official folder. So now it is working and the application is running after flashing the image.
I had used the Pinmux utility tool for generating the pinmux file but I used the default config by just selecting the pins and did not check other flags. If I had the ".pinmux" file to load in Pinmux utility and then do the update may be this mistake would not have happened.

regards
Mohit