PROCESSOR-SDK-AM335X: How to set Entry Point Address in SYSBIOS

Hi,

I'm not sure why your program had mmuTableSection at 0x8000000, but I tried an AM335x PDK example project, GPIO_LedBlink_iceAMIC110_armTestProject, and the .map file (attached) https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/GPIO_5F00_LedBlink_5F00_iceAMIC110_5F00_armTestProject.mapshows the following:

.c_int00 0x80000000 0xb4
*(.c_int00)
.c_int00 0x80000000 0xb4 C:\ti\bios_6_76_03_01\packages\gnu\targets\arm\rtsv7A\lib\boot.aa8fg(boot.oa8fg)
0x80000000 _c_int00

ti.sysbios.family.arm.a8.mmuTableSection
0x80018000 0x4000

You can compare your project with this PDK example project and find the difference. Please refer instructions here regarding how to create and build PDK example projects.

Regards,

Jianzhong

Jianzhong,

That didn't take long to fail.

Using CCS Import Projects, and navigating to the PDK folder,

The PDK folder has only two examples in it.

You'll need to create the projects according to instructions at: https://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_overview.html#pdk-example-and-test-project-creation. Basically, you'll need to

1. Install and register all SDK products in CCS.

2. Create PDK example projects:

• C:\ti\pdk_am335x_1_0_17\packages>pdksetupenv.bat
• C:\ti\pdk_am335x_1_0_17\packages>pdkProjectCreate.bat AM335x

Regards,

Jianzhong

Jianzhong,

Then CCS is not the preferred environment anymore?

I have had exactly 0.0000% success using the batch files from these packages.  Apparently written by Linux shell developers who don't have any idea about Windows.

Case in point below...

C:\ti\pdk_am335x_1_0_17\packages>pdksetupenv.bat
***************************************************
Environment Configuration:
***************************************************
SDK_INSTALL_PATH : C:/ti
PDK_INSTALL_PATH : C:/ti/pdk_am335x_1_0_17/packages
GMAKE_INSTALL_PATH : C:/ti/xdctools_3_55_02_22_core
PDK_SOC : am335x
PDK_VERSION : 1_0_17
RULES_MAKE : C:/ti/pdk_am335x_1_0_17/packages/ti/build/Rules.make
***************************************************

C:\ti\pdk_am335x_1_0_17\packages>pdkProjectCreate.bat AM335x
=========================================================================
Configuration:
SOC : AM335x
BOARD : all
ENDIAN : little
MODULE : all
PROJECT_TYPE : all
PROCESSOR : arm
PDK_SHORT_NAME : C:\ti\PDK_AM~2\packages\
=========================================================================
Checking Configuration...
Complete
=========================================================================
PDK_PARTNO : AM335
PDK_ECLIPSE_ID : com.ti.pdk.am335x
RTSC_PLATFORM_NAME : ti.platforms.evmAM3359
RTSC_TARGET : gnu.targets.arm.A8F
CCS_DEVICE : "Cortex A.AM3359.ICE_AM3359"
*****************************************************************************
Detecting all projects in PDK and importing them in the workspace C:\ti\PDK_AM~2\packages\\MyExampleProjects
Detected Test Project: EMAC_BasicExample_evmAM335x_armExampleproject
The system cannot find the path specified.
Copying macro.ini
The system cannot find the path specified.
0 file(s) copied.
Detected Test Project: EMAC_BasicExample_skAM335x_armExampleproject
The system cannot find the path specified.Cancel
Copying macro.ini
The system cannot find the path specified.
0 file(s) copied.
Detected Test Project: GPIO_LedBlink_bbbAM335x_armTestProject
The system cannot find the path specified.
Copying macro.ini
The system cannot find the path specified.
0 file(s) copied.
Detected Test Project: GPIO_LedBlink_icev2AM335x_armTestProject
The system cannot find the path specified.
Copying macro.ini
The system cannot find the path specified.
0 file(s) copied.
Detected Test Project: GPIO_LedBlink_skAM335x_armTestProject
The system cannot find the path specified.
Copying macro.ini
The system cannot find the path specified.
0 file(s) copied.
.... 
*****************************************************************************

C:\ti\pdk_am335x_1_0_17\packages>

Those PDK scripts are just used to create the CCS projects. You'll still use CCS to build and debug after the projects are created.

I do NOT enjoy troubleshooting vendors 800+ line batch files...  Because they didn't test or document it properly...

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

Quoting:

Ensure all dependent/prerequisite products are installed and registered 
with CCS before proceeding with the examples and/or unit test. Starting 
CCS after installing...

Okay...

Navigate to pdk_[soc]_[version]/packages

Okay

[Optional] Edit the product versions within the pdkProjectCreate script. 
The default settings in the pdkProjectCreate script will have the 
product versions installed with the PDK. The pdkProjectCreate script 
can be modified to use older or newer product versions based on the 
user’s development environment.

Not needed, I am using the same versions from the PDK installer.

If the CCS installation is located somewhere other than “C:\ti”, ensure 
that the pdkProjectCreate script has this location correctly specified 
by updating the CCS_INSTALL_PATH or set TOOLS_INSTALL_PATH variable

Well, it's not...  Everything is in C:\TI.

And I still get all those errors.

Well, guess what...?  Line 449 of the batch file is wrong.  My version of CCS is 10.1.1.   The batch files has 9.3.0.

This instruction is ONLY telling the use to update if they didn't put the packages in the TI folder.  There is NOTHING about the version of CCS.

Now can we get back to the original issue?

The app I create with the wizard  (Project | New CCS Project | GNU SYSBIOS) places .c_int00 at address 0x800040e0

The app I import places .c_int00 at address 0x80000000

The ONLY difference is the contents of the CFG file, which is a bunch of JAVA adding superfluous packages I do not know what they are (finding doc on them is a nightmare) and I do not need or want.

The REASON that .c_int00 is in the wrong place is because of the config/Pkg/linker.cmd.

The one from the example:

/*
 * This file was generated by linkcmd_bm_v7a.xdt from the gnu.target.arm  package.
 */

ENTRY(_c_int00)
...

/* Content from ti.sysbios.family.arm (ti/sysbios/family/arm/linkcmd.xdt): */

/* Content from ti.sysbios.family.arm.a8.intcps (ti/sysbios/family/arm/a8/intcps/linkcmd.xdt): */
ti_sysbios_family_arm_a8_intcps_Hwi_intc = 0x48200000;


SECTIONS {

    .c_int00 : {
        KEEP (*(.c_int00))
    } > REGION_TEXT

    .text : {
        CREATE_OBJECT_SYMBOLS
        KEEP (*(.resetVecs))
        KEEP (*(.text))
        *(.text.*)
        *(.gnu.linkonce.t*)
        *(.gnu.warning)
        *(.glue*)
        . = ALIGN(0x4);
        ...

And the one from the wizard:

/*
 * This file was generated by linkcmd_bm_v7a.xdt from the gnu.target.arm  package.
 */
 
ENTRY(_c_int00)
...
/* Content from ti.sysbios.family.arm (ti/sysbios/family/arm/linkcmd.xdt): */

/* Content from ti.sysbios.family.arm.a8.intcps (ti/sysbios/family/arm/a8/intcps/linkcmd.xdt): */
ti_sysbios_family_arm_a8_intcps_Hwi_intc = 0x48200000;


SECTIONS {

        .vecs : {*(.vecs)}  AT> DDR2
    ti.sysbios.family.arm.a8.mmuTableSection (NOLOAD) : {*(ti.sysbios.family.arm.a8.mmuTableSection)}  AT> DDR2
    xdc.meta (COPY) : {KEEP(*(xdc.meta))}  AT> DDR2


    .c_int00 : {
        KEEP (*(.c_int00))
    } > REGION_TEXT

    .text : {
        CREATE_OBJECT_SYMBOLS
        KEEP (*(.resetVecs))
        KEEP (*(.text))
        *(.text.*)
        *(.gnu.linkonce.t*)
        *(.gnu.warning)
        *(.glue*)
        . = ALIGN(0x4);
        KEEP (*(.ctors))
        ...

That file is MAGICALLY CREATED by this environment in a manner that is hidden from the user.

Changing that file does no good because it is re-generated.

Not only do I NOT enjoy troubleshooting other peoples batch files that are broken...\

I do NOT enjoy troubleshooting environments where they try to obfuscate and hide ALL the controls, because they think they are doing you a favor. but not having to know what and where that stuff is.

...  and then berate you for not knowing how to modify/adjust//fix issues that are coming out of that same environment that was designed to make it not necessary for you to know how it works under the covers.

Here is the ENTIRE project created by the wizard which places the .c_int00 in the wrong place.  Not a single line of code was changed from the original creation.

EmptyTest.zip

-CSW

Hi CSW,

Jianzhong is on vacation and will be able to respond in the week of June 21. Please note delay in the response for this thread.

Thanks

Great...  So nothing will happen for a week, short of me troubleshooting this obfuscated environment.

So I continued to dig into your environment and here is what I found...

The target device is a BeagleBoneBlack.

This is an app created by CCS using the menu "Project | New CCS Project" and picking "SYS/BIOS | GNU Target Examples | Typical"

I am including MY OWN interface functions, not the PDK libs. So all the GPIO calls are from source code within the project. Not linked in.

I added a file CMD in the root to set the entry point to the start of DDR:

MEMORY
{
DDR : org = 0x80000000, len = 0x20000000
}

SECTIONS {
.c_int00 : {
KEEP (*(.c_int00))
} > DDR
}

At that point, the entry is set to 0x8000000

But it is failing.

I modified the bootloader to generate some diagnostic messages. I verified that the bootloader is working correctly.  it is.

The bootloader will also load and run the Example GPIO_LedBlink_bbbAM335x_armTestProject  so I know the bootloader functions.

I reset the device, and step through the bootloader execution from address 0x402F0400. The loader correctly loads the 'app' and executes a call to the target address of 0x80000000.

Here it enters EITHER the sample program GPIO_LedBlink_bbbAM335x_armTestProject -OR- my program created with the Project | New CCS Project...

The assembly at address 0x800000 is IDENTICAL between the two apps.

However they jump to different locations at address 0x...98.

On the EXAMPLE project imported:

The instruction at address ...98 is BLX r0 and the content of R0 is 0x80000C04

I can see this in the map file (xdc_runtime_Startup_reset), and it is one of those XDC generated source files:

.text.xdc_runtime_Startup_exec__I
0x80000bd4 0x30 C:\ti\pdk_am335x_1_0_17\packages\MyExampleProjects\GPIO_LedBlink_bbbAM335x_armTestProject\Debug\configPkg\package\cfg\am335x_app_bbbam335x_pa8fg.oa8fg
0x80000bd4 xdc_runtime_Startup_exec(int0_t)
.text.xdc_runtime_Startup_reset__I
0x80000c04 0x14 C:\ti\pdk_am335x_1_0_17\packages\MyExampleProjects\GPIO_LedBlink_bbbAM335x_armTestProject\Debug\configPkg\package\cfg\am335x_app_bbbam335x_pa8fg.oa8fg
0x80000c04 xdc_runtime_Startup_reset(int0_t)
.text.xdc_runtime_System_printfExtend__I
0x80000c18 0x3c0 C:\ti\pdk_am335x_1_0_17\packages\MyExampleProjects\GPIO_LedBlink_bbbAM335x_armTestProject\Debug\configPkg\package\cfg\am335x_app_bbbam335x_pa8fg.oa8fg
0x80000c18 xdc_runtime_System_printfExtend(int0_t)
.text.xdc_runtime_SysMin_output__I
0x80000fd8 0x84 C:\ti\pdk_am335x_1_0_17\packages\MyExampleProjects\GPIO_LedBlink_bbbAM335x_armTestProject\Debug\configPkg\package\cfg\am335x_app_bbbam335x_pa8fg.oa8fg
0x80000fd8 xdc_runtime_SysMin_output(int0_t)

On the app generated by CCS, the same instruction at address is jumping to a different address. The contents of R0 is 0x80008EA8.

When I look at the map file, that is not even an entry point. It is in the middle of my function GPIO2ModuleClkConfig

.text 0x80008ca4 0x224 ./ti/source/drivers/gpio.o
0x80008ca4 GPIO1Pin23PinMuxSetup
0x80008cb8 GPIO0ModuleClkConfig
0x80008d9c GPIO1ModuleClkConfig
0x80008e1c GPIO1PinMuxSetup
0x80008e38 GpioPinMuxSetup
0x80008e48 GPIO2ModuleClkConfig
.text 0x80008ec8 0x584 ./ti/source/drivers/gpio_v2.o
0x80008ec8 GPIOModuleReset
0x80008ee4 GPIOModuleEnable
0x80008ef4 GPIOModuleDisable
0x80008f04 GPIODirModeSet
0x80008f34 GPIODirModeGet
0x80008f4c GPIOPinWrite

Therefore, where the bootstrap code is jumping to is NOT correct. All this is stuff in XDC, deep under the covers, and not anything I can find controls for.

Now, please explain how these differences occur, and where I can control the something...(XDC, GNU, Project...?) to build the app correctly.

-CSW

Hi CSW,

Sorry for not being able to help you in the past week. I'll look into this issue and get back to you by the end of this week.

Thanks for your patience.

Jianzhong

Hi CSW,

Have you tried loading and running your program through JTAG? If it works with JTAG, it should also work using the bootloader.

I found a thread that you opened a few years ago: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/662587/compiler-processor-sdk-am335x-creating-binary-file-for-sd-card. This may be what you referred to earlier. Please take a look and see if it applies to your current problem.

Thanks again for your patience.

Best regards,

Jianzhong

First, do you know how difficult it is to find stuff from years ago, since E2E erases all my notifications every few days??

It does load with the JTAG.   And obviously the bootloader doesn't run because the entry point is INT THE WRONG PLACE.  The JTAG forcibly puts the code in DDR and sets the entry point to where the linker requires it.

The EXAMPLE builds with the entry at 0x800 0000.  But a program with the CCS new project wizard does NOT.   Have you simply tried to use the new project wizard, build an empty program, and look at the map file?

If there is a statement in the CFG file that is present in the example, but not generated in the new CCS project wizard, I can't find it.

The old post you mention was placing a new CMD file in the project.... 

But WHY does the SYSBIOS example not need a CMD file, but the CCS New project does?

Why is there an obsession to hide how this works, so it's impossible to troubleshoot?

Hi Christopher,

While I let Jianzhong to address your main (remaining) issue, my few inputs on your comments in previous response.

1. >> The JTAG forcibly puts the code in DDR and sets the entry point to where the linker requires it.

No - JTAG does not forcibly put the code in DDR.. It is all controlled by the lnk cmd file used for the application. Note that CCS reads the entry symbol and initializes the PC with that address to start the execution.

2. >>The EXAMPLE builds with the entry at 0x800 0000.  But a program with the CCS new project wizard does NOT

Note that CCS is not meant only for Processor SDK release. There are various teams across TI, use CCS. So, the PDK example setting up entry point to some value, not necessarily match to CCS project wizard.  Please view them as two different approaches.

3.  >> If there is a statement in the CFG file that is present in the example, but not generated in the new CCS project wizard, I can't find it.

Same input as #2. Wizard and PDK Examples are different.

4.  >> WHY does the SYSBIOS example not need a CMD file, but the CCS New project does?

As you know, any Program needs the link cmd file to link and generate the final executable. In the SYS BIOS case, the lnk cmd file is generated from the default based on the board (platform) used for building the application. You can see the lnk cmd file used for building the application under the generated Debug folder (in CCS) - There are few depth to it - you can probably grep for the linker command file.

Sys BIOS provides some flexibility to users, to not use the linker template (default one) and instead user can provide his own template lnk cmd file.  You would need to mention this change in RTSC cfg  file, to have custom link cmd file template. 

Ref: http://software-dl.ti.com/targetcontent/legacy_files/targetcontent/rtsc/xdctools_3_10/xdctools_3_10_03/exports/docs/cdoc/xdc/cfg/Program.html#xdoc-desc

Please look for Program.linkTemplate  in above html page. Note that this is java script centric. so you may need to write the template in java script.

Hope this helps to clarify your questions.

Thanks Aravind for the excellent explanations. 

Christopher,

I just wanted to add that you can find your older posts by searching. For example, if you put "site:e2e.ti.com Entry Point Address in SYSBIOS am335x" in Google search bar, you should be able to find the thread that I provided earlier.

Best regards,

Jianzhong

Just an FYI...   45 minutes of a detailed reply to try to get a better understanding....  Was eaten by you web forum popping up "Error, please try again or contact the administrator"

This process is horrid, and I will not recreate it tonight, while this mad at your service.

Sorry about that experience. It must have been very frustrating. The web server can sometimes have hiccups.

'sometimes' ?  This happens routinely (25% of the time).  No one seems to care to fix it.  Or add some kind of auto-save.

Here we go again...  Lets hope this one POSTS...

The subject "How to Set the Entry Point" still mostly applies.  How is it set in the Example, and why is it NOT set in a wizard based project?

Import an example:

Build and examine the map file:

It is correct.

Change the target from ti.platforms.evmAM3359  to ti.platforms.beaglebone  and rebuild...  NO CHANGE

Create a SYSBIOS project using the wizard.

The files are there, auto-generated:

Build and examine the map file:

IT IS WRONG.  9The c_int00 code block appears the same size...  but in the wrong place )

In BOTH cases, the settings are Platform:gnu.targets.arm.A8F   and Target:  ti.platforms.beaglebone

In BOTH cases, the environment is creating the linker script.  

in BOTH cases, the XDC is 3.55 and SYSBIOS is 6.76

In the case that DOES NOT correctly, simply throwing in more "products" in the project settings makes no difference.

Trying to find what is in the CFG file that is doing it has turned up nothing.

I can fix the second one ONLY by adding my own CMD file.  But it IS NOT there in the example.

Last time, my other post helped me fix the entry point by what now appears to be a work-around HACK.

WHAT IS THE DIFFERENCE between these two projects?

WHY does one generate a linker script that correctly sets the entry point, and the OTHER project doesn't??

WHY does it need a HACK?