This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM335x can't call a function

Other Parts Discussed in Thread: AM3359, LINUXEZSDK-SITARA, AM3358

Hi All,

Please see the one-file program below. What would make this not even get to

the line of the function call?

Execution gets through when the code is moved out of the function into main().

It is very odd.

 

I have IAR ver. 6.60.1.5104.

In addition to upgrading to the latest EWARM, and the latest pod firmware (v4):

In Project - Options:

- General Options - Target, I set the Device to "TexasInstruments am3359";

and the Core was automatically set to Cortex-A8.

- Debugger - Setup: I changed the Driver to "I-jet/JTAGjet".

- Debugger - Plugins: deselect "Code Coverage".

 

- Debugger - Use macro file: Disable_WDT.mac (see the .zip).

 

I can't run from main() to just before the function call to

GPIO0ModuleClkConfig(); it never gets there and I have to stop it manually.

 

It works when the GPIO0ModuleClkConfig() code is moved into main.

A difference is that there is this PUSH {R7, LR} instruction before the

function call that doesn't seem to be there when the code is simply in

main(), that can be seen when debugging.

 

This is almost the same one-file program that I was asking about previously,

in which it wasn't getting through the last "while" wait. The answer to that

was that I was not even debugging, but simulating, and the above changes

got me debugging, with the help of IAR tech support. IAR is stumped on

this problem, however. It gets to the function call in simulation, so there

must be something about debugging on a new board. Any ideas? I think

I have enough stack; it's only trying to push two registers before the

function call.

----------------------------------------------------

#define HWREG(x) (*((volatile unsigned int*)(x)))

#define PRCM_REGS (0x44E00000)
#define SOC_CM_WKUP_REGS (PRCM_REGS + 0x400)

#define CM_WKUP_CLKSTCTRL (0x0)
#define CM_WKUP_GPIO0_CLKCTRL (0x8) /* For GPIO0 */

/* CLKSTCTRL */
#define CM_WKUP_CLKSTCTRL_CLKACTIVITY_GPIO0_GDBCLK (0x00000100u) /* For GPIO0 */

/* GPIO0_CLKCTRL */
#define CM_WKUP_GPIO0_CLKCTRL_IDLEST (0x00030000u) /* For GPIO0 */
#define CM_WKUP_GPIO0_CLKCTRL_IDLEST_SHIFT (0x00000010u) /* For GPIO0 */
#define CM_WKUP_GPIO0_CLKCTRL_IDLEST_FUNC (0x0u) /* For GPIO0 */

#define CM_WKUP_GPIO0_CLKCTRL_MODULEMODE (0x00000003u)
#define CM_WKUP_GPIO0_CLKCTRL_MODULEMODE_ENABLE (0x2u) /* For GPIO0 */

#define CM_WKUP_GPIO0_CLKCTRL_OPTFCLKEN_GPIO0_GDBCLK (0x00040000u) /* For GPIO0 */

void GPIO0ModuleClkConfig(void)
//int main()
{
/* Writing to MODULEMODE field of CM_WKUP_GPIO0_CLKCTRL register. */
HWREG(SOC_CM_WKUP_REGS + CM_WKUP_GPIO0_CLKCTRL) |=
CM_WKUP_GPIO0_CLKCTRL_MODULEMODE_ENABLE;

/* Waiting for MODULEMODE field to reflect the written value. */
while(CM_WKUP_GPIO0_CLKCTRL_MODULEMODE_ENABLE !=
(HWREG(SOC_CM_WKUP_REGS + CM_WKUP_GPIO0_CLKCTRL) &
CM_WKUP_GPIO0_CLKCTRL_MODULEMODE));

/*
** Writing to OPTFCLKEN_GPIO0_GDBCLK field of CM_WKUP_GPIO0_CLKCTRL
** register.
*/
HWREG(SOC_CM_WKUP_REGS + CM_WKUP_GPIO0_CLKCTRL) |=
CM_WKUP_GPIO0_CLKCTRL_OPTFCLKEN_GPIO0_GDBCLK;

/* Waiting for OPTFCLKEN_GPIO0_GDBCLK field to reflect the written value. */
while(CM_WKUP_GPIO0_CLKCTRL_OPTFCLKEN_GPIO0_GDBCLK !=
(HWREG(SOC_CM_WKUP_REGS + CM_WKUP_GPIO0_CLKCTRL) &
CM_WKUP_GPIO0_CLKCTRL_OPTFCLKEN_GPIO0_GDBCLK));

/* Writing to IDLEST field in CM_WKUP_GPIO0_CLKCTRL register. */
while((CM_WKUP_GPIO0_CLKCTRL_IDLEST_FUNC <<
CM_WKUP_GPIO0_CLKCTRL_IDLEST_SHIFT) !=
(HWREG(SOC_CM_WKUP_REGS + CM_WKUP_GPIO0_CLKCTRL) &
CM_WKUP_GPIO0_CLKCTRL_IDLEST));

/*
** Waiting for CLKACTIVITY_GPIO0_GDBCLK field in CM_WKUP_GPIO0_CLKCTRL
** register to attain desired value.
*/
while(CM_WKUP_CLKSTCTRL_CLKACTIVITY_GPIO0_GDBCLK !=
(HWREG(SOC_CM_WKUP_REGS + CM_WKUP_CLKSTCTRL) &
CM_WKUP_CLKSTCTRL_CLKACTIVITY_GPIO0_GDBCLK));

// return 0;
}

int main() /* Establish only GPIO0ModuleClkConfig */
{

GPIO0ModuleClkConfig();

return 0;
}

----------------------------------------------------

  • Hi,

    1) Can you please let us know which AM3359 EVM you are using?

    2) Have you tried executing any EWARM projects provided with StarterWare package?

    3) Also IAR Embedded Workbench 6.50 is used for the latest release

  • Hi Jeethan,

    I am using the TMDXEVM3358-SK-LCD evaluation module. Execution in
    that gets through main to the function call, although there is an
    error on download and debug in IAR:
    "The stack pointer for stack 'FIQ_STACK' (currently 0x40308400)
    is outside the stack range (0x40308500 to 0x40308540)"
    This error is not shown when I am trying my new board, but it is
    with the new board that I have the problem.

    I changed to use IAR ver. 6.50.6.4958.

    To get to essences, I changed my code to the following as the
    entire program:
    --------------------------
    void myfunc(void)
    {
    }

    int main()
    {
    myfunc();
    return 0;
    }
    --------------------------
    The problem is that it doesn't even run from main to the function
    call, where it would be poised to call the function as the next
    step, never mind calling the function. There is a PUSH {R7, LR}
    instruction in the assembly language that it's never getting
    through, after the label main: and before the BL to myfunc. This
    is the same PUSH {R7, LR} in the same place that was there when I
    had code inside the function.
    I didn't change Project - Options. However, I can specify or not
    specify the "Code Coverage" plugin in Debugger, and it doesn't
    make any difference.

    If I can't push to the stack, but I can run code in main, there
    must be a problem with pushing to the stack. There might be a
    very simple answer to this. Since the above program is
    *complete*, do I need some memory initialization code?

    I haven't tried other EWARM examples. I may go and do so.

    Best regards,

  • I'm pretty sure my new board (a custom board, not the EVM) has a
    memory access problem somehow.
    I tried Getting_Started.ewp at
    C:\Program Files (x86)\IAR Systems\Embedded Workbench 6.5\arm\examples\TexasInstruments\AM335x\AM335x_EVM\Getting_Started\
    and deselected "Run to main" in Project-Options - Debugger. I am
    now running IAR ver 6.50.6.4958; the problem is the same as in
    ver 6.60.
    In the below, it hangs on the line:
    0x402f04d0: 0x1bfffff9 BLNE ?Veneer (1) for __iar_data_init3 ; 0x402f04bc
    At ?Veneer (1) for __iar_data_init3 is the first access to
    memory rather than a register. I'm not sure why it's hanging on
    the branch rather than on the "LDR PC, [PC, #-0x4]"
    instruction, however.

    Please see my previous messages above in this thread for what I
    have set.

    Selecting the "Code Coverage" plugin doesn't seem to make any
    difference. I'm not using the macro file: Disable_WDT.mac.

    The voltages are, on my new board:

    VDDSHV1/GPMC = VDIG1= 2.24V

    VDDSHV2/MMCSD-B = VMMC = 3.3V

    VDDSHV3/GEMAC-B = VMMC = 3.3V

    VDDSHV4/MMCSD-A = VMMC = 3.3V

    VDDSHV5/GEMAC-A = VMMC = 3.3V

    VDDSHV6/GENERAL = VAUX2 = 3.3V

    VDDSHV1 should be 3.3V; would this cause a problem? I am getting
    that fixed. Can any software problem be causing this?
    I seem to be able to write bytes to the stack area of memory
    using the debugger.

    We are going to be a paying customer of TI, buying AM3359 micros
    for these boards when we get them working, so we need this issue
    solved.

    -----------------------------------------------------------------

    ?cstartup:
    __iar_program_start:
    0x402f043c: 0xe10f0000 MRS R0, CPSR
    BIC r0, r0, #MODE_MSK ; Clear the mode bits
    0x402f0440: 0xe3c0001f BIC R0, R0, #31 ; 0x1f
    ORR r0, r0, #IRQ_MODE ; Set IRQ mode bits
    0x402f0444: 0xe3800012 ORR R0, R0, #18 ; 0x12
    MSR cpsr_c, r0 ; Change the mode
    0x402f0448: 0xe121f000 MSR CPSR_c, R0
    LDR sp, =SFE(IRQ_STACK) ; End of IRQ_STACK
    0x402f044c: 0xe59fd034 LDR SP, _?0 ; FIQ_STACK$$Base
    BIC sp,sp,#0x7 ; Make sure SP is 8 aligned
    0x402f0450: 0xe3cdd007 BIC SP, SP, #7
    BIC r0, r0, #MODE_MSK ; Clear the mode bits
    0x402f0454: 0xe3c0001f BIC R0, R0, #31 ; 0x1f
    ORR r0, r0, #FIQ_MODE ; Set FIR mode bits
    0x402f0458: 0xe3800011 ORR R0, R0, #17 ; 0x11
    MSR cpsr_c, r0 ; Change the mode
    0x402f045c: 0xe121f000 MSR CPSR_c, R0
    LDR sp, =SFE(FIQ_STACK) ; End of FIQ_STACK
    0x402f0460: 0xe59fd024 LDR SP, _?1 ; FIQ_STACK$$Limit
    BIC sp,sp,#0x7 ; Make sure SP is 8 aligned
    0x402f0464: 0xe3cdd007 BIC SP, SP, #7
    BIC r0 ,r0, #MODE_MSK ; Clear the mode bits
    0x402f0468: 0xe3c0001f BIC R0, R0, #31 ; 0x1f
    ORR r0 ,r0, #SYS_MODE ; Set System mode bits
    0x402f046c: 0xe380001f ORR R0, R0, #31 ; 0x1f
    MSR cpsr_c, r0 ; Change the mode
    0x402f0470: 0xe121f000 MSR CPSR_c, R0
    LDR sp, =SFE(CSTACK) ; End of CSTACK
    0x402f0474: 0xe59fd014 LDR SP, _?2 ; CSTACK$$Limit
    BIC sp,sp,#0x7 ; Make sure SP is 8 aligned
    0x402f0478: 0xe3cdd007 BIC SP, SP, #7
    BL __iar_init_core
    0x402f047c: 0xe1a00000 MOV R0, R0
    BL __iar_init_vfp
    0x402f0480: 0xeb000003 BL __iar_init_vfp_v6 ; 0x402f0494
    B __cmain
    0x402f0484: 0xea00000e B ?main ; 0x402f04c4
    _?0:
    0x402f0488: 0x40309308 DC32 FIQ_STACK$$Base
    _?1:
    0x402f048c: 0x40309348 DC32 FIQ_STACK$$Limit
    _?2:
    0x402f0490: 0x40309208 DC32 CSTACK$$Limit
    __iar_init_vfp_v6:
    0x402f0494: 0xee110f50 MRC p15, #0, R0, C1, C0, #2
    0x402f0498: 0xe38008f0 ORR R0, R0, #15728640 ; 0xf00000
    0x402f049c: 0xee010f50 MCR p15, #0, R0, C1, C0, #2
    0x402f04a0: 0xe3a00001 MOV R0, #1
    0x402f04a4: 0xee070f95 MCR p15, #0, R0, C7, C5, #4
    __iar_init_vfp:
    0x402f04a8: 0xe3a00440 MOV R0, #1073741824 ; 0x40000000
    0x402f04ac: 0xeee80a10 VMSR FPEXC, R0
    0x402f04b0: 0xe3a007c0 MOV R0, #50331648 ; 0x3000000
    0x402f04b4: 0xeee10a10 VMSR FPSCR, R0
    0x402f04b8: 0xe12fff1e BX LR
    ?Veneer (1) for __iar_data_init3:
    0x402f04bc: 0xe51ff004 LDR PC, [PC, #-0x4] ; [0x402f04c0] __iar_data_init3
    0x402f04c0: 0x402f04ed DC32 __iar_data_init3
    ?main:
    __cmain:
    0x402f04c4: 0xe3a00001 MOV R0, #1
    0x402f04c8: 0xfa000006 BLX __low_level_init ; 0x402f04e8
    0x402f04cc: 0xe3500000 CMP R0, #0
    0x402f04d0: 0x1bfffff9 BLNE ?Veneer (1) for __iar_data_init3 ; 0x402f04bc
    _call_main:
    0x402f04d4: 0xe3a00000 MOV R0, #0
    0x402f04d8: 0xfb000162 BLX main ; 0x402f0a6a
    _main:
    0x402f04dc: 0xfa0001dd BLX exit ; 0x402f0c58
    0x402f04e0: 0xeb0001de BL __exit ; 0x402f0c60
    0x402f04e4: 0xeafffffd B 0x402f04e0
    __low_level_init:
    0x402f04e8: 0x2001 MOVS R0, #1
    0x402f04ea: 0x4770 BX LR
    __iar_data_init3:
    0x402f04ec: 0xb510 PUSH {R4, LR}
    0x402f04ee: 0x4907 LDR.N R1, [PC, #0x1c] ; [0x402f050c] 0xd44 (3396)
    0x402f04f0: 0x4479 ADD R1, R1, PC
    -----------------------------------------------------------------

    I am also putting this back on the "AM3x Sitara ARM Processors
    Forum".

  • The link in the "AM3x Sitara ARM Processors
    Forum": http://e2e.ti.com/support/arm/sitara_arm/f/791/p/290435/1013504.aspx

  • Hi,

    As suggested previously, have you tried running one of the examples provided with the StarterWare release package on your board? That should make it easier to confirm if it's a board issue.

    Regards,
    Mugdha

  • Well, my second previous message above was a report on running one of the examples provided with EWARM ver. 6.50.6.4958.


  • The voltages have been fixed now in repaired boards; see my hardware thread at http://e2e.ti.com/support/arm/sitara_arm/f/791/p/290435/1015025.aspx#1015025 , and I tried an actual Starterware example, C:\ti\AM335X_StarterWare_02_00_00_07\examples\evmskAM335x\gpio_card_detect\gpioCardDetect.c, using the same methodology as in my previous report, but I still get the same problem; it hangs up on the following line: 

    0x402f0b64: 0x1bfffff9     BLNE      ?Veneer (1) for __iar_data_init3 ; 0x402f0b50:

    in:

    __iar_program_start:
    0x402f0ad0: 0xe10f0000 MRS R0, CPSR
    0x402f0ad4: 0xe3c0001f BIC R0, R0, #31 ; 0x1f
    0x402f0ad8: 0xe3800012 ORR R0, R0, #18 ; 0x12
    0x402f0adc: 0xe121f000 MSR CPSR_c, R0
    0x402f0ae0: 0xe59fd034 LDR SP, [PC, #0x34] ; [0x402f0b1c] FIQ_STACK$$Base
    0x402f0ae4: 0xe3cdd007 BIC SP, SP, #7
    0x402f0ae8: 0xe3c0001f BIC R0, R0, #31 ; 0x1f
    0x402f0aec: 0xe3800011 ORR R0, R0, #17 ; 0x11
    0x402f0af0: 0xe121f000 MSR CPSR_c, R0
    0x402f0af4: 0xe59fd024 LDR SP, [PC, #0x24] ; [0x402f0b20] FIQ_STACK$$Limit
    0x402f0af8: 0xe3cdd007 BIC SP, SP, #7
    0x402f0ae8: 0xe3c0001f BIC R0, R0, #31 ; 0x1f
    0x402f0aec: 0xe3800011 ORR R0, R0, #17 ; 0x11
    0x402f0af0: 0xe121f000 MSR CPSR_c, R0
    0x402f0af4: 0xe59fd024 LDR SP, [PC, #0x24] ; [0x402f0b20] FIQ_STACK$$Limit
    0x402f0af8: 0xe3cdd007 BIC SP, SP, #7
    0x402f0afc: 0xe3c0001f BIC R0, R0, #31 ; 0x1f
    0x402f0b00: 0xe380001f ORR R0, R0, #31 ; 0x1f
    0x402f0b04: 0xe121f000 MSR CPSR_c, R0
    0x402f0b08: 0xe59fd014 LDR SP, [PC, #0x14] ; [0x402f0b24] CSTACK$$Limit
    0x402f0b0c: 0xe3cdd007 BIC SP, SP, #7
    0x402f0b10: 0xe1a00000 MOV R0, R0
    0x402f0b14: 0xeb000003 BL __iar_init_vfp_v6 ; 0x402f0b28
    0x402f0b18: 0xea00000e B ?main ; 0x402f0b58
    0x402f0b1c: 0x4030d300 DC32 FIQ_STACK$$Base
    0x402f0b20: 0x4030d340 DC32 FIQ_STACK$$Limit
    0x402f0b24: 0x4030d200 DC32 CSTACK$$Limit
    __iar_init_vfp_v6:
    0x402f0b28: 0xee110f50 MRC p15, #0, R0, C1, C0, #2
    0x402f0b2c: 0xe38008f0 ORR R0, R0, #15728640 ; 0xf00000
    0x402f0b30: 0xee010f50 MCR p15, #0, R0, C1, C0, #2
    0x402f0b34: 0xe3a00001 MOV R0, #1
    0x402f0b38: 0xee070f95 MCR p15, #0, R0, C7, C5, #4
    __iar_init_vfp:
    0x402f0b3c: 0xe3a00440 MOV R0, #1073741824 ; 0x40000000
    0x402f0b40: 0xeee80a10 VMSR FPEXC, R0
    0x402f0b44: 0xe3a007c0 MOV R0, #50331648 ; 0x3000000
    0x402f0b48: 0xeee10a10 VMSR FPSCR, R0
    0x402f0b4c: 0xe12fff1e BX LR
    ?Veneer (1) for __iar_data_init3:
    0x402f0b50: 0xe51ff004 LDR PC, [PC, #-0x4] ; [0x402f0b54] __iar_data_init3
    0x402f0b54: 0x402f0b81 DC32 __iar_data_init3
    ?main:
    __cmain:
    0x402f0b58: 0xe3a00001 MOV R0, #1
    0x402f0b5c: 0xfa000006 BLX __low_level_init ; 0x402f0b7c
    0x402f0b60: 0xe3500000 CMP R0, #0
    0x402f0b64: 0x1bfffff9 BLNE ?Veneer (1) for __iar_data_init3 ; 0x402f0b50
    _call_main:
    0x402f0b68: 0xe3a00000 MOV R0, #0
    0x402f0b6c: 0xfaffffb4 BLX main ; 0x402f0a44


  • Any ideas?

  • Hi,

         Looking at the above discussions i am not sure if the issue is with board, debugger, emulator or .mac file (which configures DDR & PLL).

         So lets try to isolate the issue. Can you try uart or mmc boot method described at http://processors.wiki.ti.com/index.php/Quick_Start_Guide_StarterWare_02.00.XX.XX_%28supports_AM335x%29

         The above process is independent of IAR tool chain. this will help in first level of narrowing down the issue.

    Regards

    Baskaran

  • I'll look into that. In the meantime, did you read my other thread?

  • How about my post above, of Sep 11 2013 13:57PM which refers to my simple program with the blank myfunc()? In that, as in the first post in this thread, it can run to main() to begin with, but cannot get from "main:" to the branch to the function. Since it can run to main() in these simpler programs, does that tell you anything?

    Also, I am not using any .mac file. Is one necessary, to configure DDR & PLL? Since I am a beginner here, the problem might be easy to solve. Is there a .mac in Starterware that I can use? Where is it invoked in the IAR IDE? General Options - Debugger - Setup - Setup macros?


  • Hi,

    A .mac file is needed. You can locate one inside the StarterWare repo at this location StarterWare/tools/ewarm/AM335x_*.mac.

    For more information please refer to http://processors.wiki.ti.com/index.php/AM335X_StarterWare_Environment_Setup#IAR_Embedded_Workbench_6.XX_Projects

    Regards,

    Jeethan

  • Looks like stack contents are corrupted. Basically this could happen if you don't run the mac file.

    Try to include mac file and share the progress.

    Regards

    Baskaran

  • I tried am335x.mac from
    C:\Program Files (x86)\IAR Systems\Embedded Workbench 6.5\arm\examples\TexasInstruments\AM335x\AM335x_EVM\Getting_Started\config\
    as well as each of AM335x_DDR2.mac and AM335x_DDR3.mac from
    StarterWare/tools/ewarm/ .
    I invoked them one at a time in the IAR IDE in General Options - Debugger -
    Setup - Setup macros - Use macro file(s)
    I tried them on each of
    C:\Program Files (x86)\IAR Systems\Embedded Workbench 6.5\arm\examples\TexasInstruments\AM335x\AM335x_EVM\Getting_Started\
    and
    C:\ti\AM335X_StarterWare_02_00_00_07\examples\evmskAM335x\gpio_card_detect\gpioCardDetect.c
    without success; they still get locked up on the line:
    BLNE ?Veneer (1) for __iar_data_init3.
    How do I know whether or not a macro file is compatible with my hardware? I am
    using a new board. I didn't use a macro file with the evaluation module, and the
    code got through on that.
    Where can I find information on how to program a macro file? Do you think I'll
    have to modify one for my new hardware?

  • I'll be attempting the MMC boot method.

    Meanwhile, I really need information on the following:

    Where can I find information on how to program a macro file? Do you think I'll
    have to modify one for my new hardware?

    So if a macro file is needed, how would the code run in real life? I would think that all that should be needed is the code to download to the microcontroller. ?


  • if the DDR used in your custom board is different from what is used in TI boards, you need to modify them. Can you share the DDR part number used in oyur board.

    macro file vs real life - in real life the tasks done by macro file has to be done by bootloader. In final products bootloader runs first and then the actual application.

    Regards

    Baskaran

  • Hi,

    From the above post it is mentioned that you are using a custom board.

    1) Can you please share  more details on your board?

    2) I think you tried to execute EVM and SK examples on your custom board. You may have to take a look at the DDR chip on your board. If it deviates from the DDR used in EVM(DDR2) or SK(DDR3) then you may have to modify the macro file to suit your need.

    Regards,

    Jeethan

  • I think I'm just trying to run in internal memory of the XAM3359ZCZ. As noted in
    my hardware thread, everything for now is in internal memory, from 0x402F0400 to
    0x4030FFFF. The IAR debugger is putting ROM in 0x402F0400 to 0x40307FFF and RAM
    in 0x40308000 to 0x4030FFFF. All this is RAM in the AM335x. Getting into the DDR
    and the PLL may be getting ahead of where I'm at. Is the PLL needed for running
    in internal memory? I am a beginner on this technology. I have a Micron DDR3
    SDRAM, MT41J128M16JT-125, but I don't think that's relevant right now. See my
    posts above, from the top; I am trying to figure out why it hangs on a PUSH
    instruction or a BLNE, just running in internal memory, and one of my programs
    noted above, that has this problem, is almost trivial. Do you see the one I
    mean, that consists of only a single function call to an empty function? Why
    would debugging and execution get through many assembly-language instructions
    and only have problems on the above two?
    IAR is setting up the following in Project - Options - Linker - Stack/Heap Sizes:
    CSTACK 0x1200, SVC_STACK 0x40, IRQ_STACK 0x100, FIQ_STACK 0x40, UND_STACK 0x40,
    ABT_STACK 0x40, HEAP 0x400.
    What kind of board details might help? I think I'm just trying to operate the
    micro at this point.
    I am going to try the things that are suggested, in case they help.

  • Simple code has got to be able to run, doesn't it, without a .mac? How else could the bootloader run in order to *run* *code* in order to configure things? Another simple program I tried hangs on a CMP assembly language instruction. I have provided a couple of programs of varying simplicity above, in previous messages.

    For example, I may need a macro file to be able to boot from a MicroSD card. Do I? I may need macro files for other reasons. Where is the location of documentation on how to write macro files? I am going to need answers to intermediate questions while I try some things that you have suggested.

  • My new board is modeled after the TMDXEVM3358-SK-LCD evaluation module and should work the same way. How do I launch a bootloader, an MLO, from a MicroSD card on this module? Where is the information on this? It would help if you could provide that location, since it is not immediately obvious from a search.

  • No experience with this platform. My platform is the C6748 but I would expect TI to follow the same pattern. I usually start at the Wiki and click through.

    http://processors.wiki.ti.com
    http://processors.wiki.ti.com/index.php/AM335x_General_Purpose_EVM_HW_User_Guide
    http://processors.wiki.ti.com/index.php/AM335x_Software_Design_Guide
    http://processors.wiki.ti.com/index.php/AM335x_Starter_Kit_ID_Memory_Programming

    http://www.ti.com/tool/linuxezsdk-sitara
    http://software-dl.ti.com/sitara_linux/esd/AM335xSDK/latest/index_FDS.html
    http://processors.wiki.ti.com/index.php/Sitara_SDK_Release_Notes
    http://processors.wiki.ti.com/index.php/AM335x-PSP_04.06.00.07_Release_Notes
    http://processors.wiki.ti.com/index.php/AM335x_PSP_User%27s_Guide

    I think the last one might be the one you want.

  • Hi,

    These are the links that you can follow for any queries related to StarterWare:

    http://processors.wiki.ti.com/index.php/StarterWare

    http://processors.wiki.ti.com/index.php/Quick_Start_Guide_StarterWare_02.00.XX.XX_(supports_AM335x)

    http://processors.wiki.ti.com/index.php/StarterWare_Getting_Started_02.00.XX.XX

    http://processors.wiki.ti.com/index.php/StarterWare_02.00.01.01_User_Guide

    http://processors.wiki.ti.com/index.php/StarterWare_02.00.01.01_Release_Notes

    1) Regarding your query pertaining to mac file, a mac file is not needed to boot the board using SD card(i.e. MLO and app). What configurations are done in a mac file will be done by the bootloader(i.e. MLO in this case). Further information on boot and flashing via SD card is present at this link http://processors.wiki.ti.com/index.php/AM335X_StarterWare_Booting_And_Flashing#Booting_Via_SD_Card. Hope this clarifies your doubt regarding booting via SD card.

    2) Now coming to programming a mac file.  Mac file has functions which shall configure the DDR, PLLs, EMIF, Clocks etc. When booting via SD card the MLO does this. When we load a program through a debugger we only load the application binary. Hence in this case the required bootloader configurations are done in a MAC file.

    3) The existing mac files given with StarterWare package are designed for DDR2 and DDR3. Hence you can take reference from one of this file to update the mac file for your need. What i want to deduce is the sequence you call the functions and the values you pass are really critical and in this case you may have to look into the changes on your board and hence program. For more information on programming a mac file one can look into the Generic IAR documentation.

    4) We are not able to help you with the issue that you are facing, cause we have not come across this. It would be better if you can post this query in the IAR forums where the IAR folks can help you out.

    Regards,

    Jeethan

  • Thanks for some specific answers, such as booting via the MicroSD card.

    TI needs to be supporting its customers. I am having TI issues and this is the closest forum. You can't be too narrow. Please bring in the required expertise on your end as necessary. I am going to need answers to questions when it is not clear or very easy for me to find on my own. I am getting the IAR support that I require from IAR.

  • A summary:

    I am not running Linux and am not trying to access SDRAM, I don't think... I
    have custom hardware that is modeled after the TI TMDXEVM3358-SK-LCD evaluation
    module. I have just started on it and can connect with the debugger; I am using
    IAR, with very small test programs. Code that runs in main() can access hardware
    registers and get through while loops, but when I put that code into a function,
    execution hangs on a PUSH instruction that the compiler puts there before
    branching to the function. That still happens even when I make the function
    trivial, empty.
    All this code can run in the EVM.
    Trying some Starterware code, I get a hang on a BLNE instruction before it even
    gets to "main:". A semi-trivial program that just runs in a loop and increments
    two variables and tests them hung on a CMP R0,R2 instruction every time I tried
    it, for a few days. Later the loop worked. Also later the partial Startware code
    hung on a different branch instruction before getting to "main:".
    I have not yet managed to enable the regulator that supplies the voltage to the
    DDR3 SDRAM, and as far as I know, my simple programs are running in the micro's
    SRAM starting at 0x402F0400.
    It sure looks like a problem with the micro, and we are having our boards
    reworked to get a non-experimental micro, preferably silicon rev 2.1, but I want
    to make sure that I am doing all that I can to get code running, myself.

  • A Starterware example that I tried was:
    C:\ti\AM335X_StarterWare_02_00_00_07\examples\evmskAM335x\gpio_card_detect\gpioCardDetect.c
    I cut it down to just the first three function calls in main(). However, these
    examples never even get to main(); they lock up --I have to click to stop
    execution-- on a branch instruction beforehand.

    A semi-trivial example that contains only some variable incrementing and a
    relative test was hanging on a CMP R0,R2 instruction. Then later it wasn't.

    I agree that it seems hard to believe that even the experimental silicon would
    lock up on instructions. It is verrrrrry innnnnteresting that after a while the
    instructions changed on which I got hangs.

    I can keep in mind trying an eval kit with the same level processor, an AM3359
    rather than an AM3358.

    I have been looking at my compiler settings. .intvec start is 0x402F0400, ROM is
    0x402F0400 to 0x40307FFF, RAM is 0x40308000 to 0x4030FFFF, and
    Stack/Heap Sizes are:
    CSTACK 0x1200, SVC_STACK 0x40, IRQ_STACK 0x100, FIQ_STACK 0x40, UND_STACK 0x40,
    ABT_STACK 0x40, HEAP 0x400.

    In the memory map in the spruh73i.pdf userguide or TRM, this crosses the "ROM"
    over from SRAM internal to L3 OCMC0. Could that cause a problem? The L3 OCMC0 is
    described as "32-bit Ex/RW OCMC SRAM". I'll have to read more about that.

    For an FAE for me, I wonder if someone can find me a reference or a link to
    select one? I am located in Charlottetown, PEI, Canada. Today in Canada we just
    use two-letter abbreviations for the provinces, so we just write "PE" instead of
    "PEI".

  • I have been able to find little information about the L3 OCMC0. It is listed as being from 0x40300000 to 0x4030FFFF in the TRM. Does it require any initialization or can it be relied on automatically just like the internal SRAM just below it? Since the internal SRAM is 64-1kB and the L3 OCMC0 is 64kB, does that mean that the internal RAM of the AM335x is 128-1 = 127 kB? That first kB is Reserved.

  • I changed my memory plan to use only the SRAM internal and to stay out of the
    L3 OCMC0, and code execution now gets through the PUSH {R7, LR} instruction.
    So what needs to be working or initialized to get the 64 kB of L3 OCMC0 going?
    What kind of problems can stop it? Is there actually 64 kB of physical memory on
    the chip for that 0x4030 0000 - 0x4030 FFFF, as per the TRM?

  • I moved the thread to the Sitara forum. I hope someone on this forum may have more insights into the issue you are facing.

    Regards,

    Mugdha

  • I changed my memory plan to use only the SRAM internal and to stay out of the
    L3 OCMC0, and code execution now gets through the PUSH {R7, LR} instruction.
    So what needs to be working or initialized to get the 64 kB of L3 OCMC0 going?
    What kind of problems can stop it? Is there actually 64 kB of physical memory on
    the chip for that 0x4030 0000 - 0x4030 FFFF, as per the TRM?

  • I do know that there is some set up required to use the OCMC, but not sure what the sequence is. Typically when you boot from NAND/NOR/UART/USB/etc. the boot ROM sets it up for you. I don't use starterware much, but I noticed some example code that changes the OCMC clocks. Look in examples/beaglebone/demo/am335x_clock_data.c.

    Steve K.