AM335x can't call a function

Everything for now is in internal memory, from 0x402F0400 to 0x4030FFFF. What kind of info about internal memory can you point me to?
The IAR debugger is putting ROM in 0x402F0400 to 0x40307FFF and RAM in 0x40308000 to 0x4030FFFF. All this is RAM in the AM335x. Would the bad voltage cause problems with internal memory? I seem to be able to write to this area using the debugger; why do you suppose an instruction would have trouble?

Best regards,

As best as I can determine from my hardware guy, and checking the voltages myself, the voltages have been fixed on repaired boards that I received yesterday, but this problem persists. I wonder if bizarre instruction problems like these can be caused by the experimental AM335x micro that I have? I also cannot get through a PUSH {R7, LR} instruction in other code, that gets put in before function calls. I have the XAM3359ZCZ (model code copied right off of the chip) micro on my boards, which has silicon rev 1.0.

Best regards,

Any ideas?

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.

If the example code runs on an EVM but not on your hardware this suggests one of two things to me:

1. The code has some hardware dependencies for the EVM which your board does not replicate (as an example, I2C configuration calls to a PMIC).
2. Issues with the hardware itself.

It seems like you have already found at least one hardware problem, so it's definitely worthwhile to look over the board again to ensure nothing else it out of place. In case you have not already seen it I strongly suggest going over the Schematic Checklist. It's by no means comprehensive, but it's a good start.

I don't have IAR so I have no idea what that code is doing, but in my experience your symptoms fall into one of those two categories. The AM335x has been around for a while and a lot of folks have been successful in using it, so once you narrow down the root cause I am confident you will be able to get it up and running as well.

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.