AM335x custom board, DDR3 issues

cobsonchael

Other Parts Discussed in Thread: AM3358, AM3352, SYSBIOS

hello

so i just got our boards yesterday afternoon. it appears our emulator (spectrum digital XDS560v2 LC traveler) connects just fine and our GEL file seems to run without issue. my problem is with the DDR3 and i could use some help. i should add that this is our very first experience with ARM and the 3352 and DDR3 so we are newbies all around.

so here is what has been done:

i have used the GEL file from the beaglebone black as a starter since that uses an AM3358 and i was thinking it would work fine for me. i adjusted the clock frequencies since we are using 19.2MHz and i adjusted the DDR register values. the first thing i did was run the read/write leveling out file. i took the values given, used those as the new seed values and i ran again, and i did that a few more times until it seemed to stop changing much. i hope that was the right thing to do. i double checked my ddr pll settings and i think i am getting 400MHz out of the pll.

i've gone over my timing a few times and i don't think i have anything wrong there. i am using the spreadsheet with the right tab for DDR3 to figure out my values. i believe i have the right configuration values for my DDR3 chip. i am hoping somebody can point out the error of my ways and it is something as simple as i fudged up a value

what happens is:

when i open a memory window to 0x80000000 and try to change the value of 1 byte i get up to 6 other bytes that change (but the one i tried to change did not change). sometimes it just changes one byte but it is never the byte i am trying to change. refreshing the memory window does not result in random results, which is nice.

so i am kind of at a point where i do not know exactly where to go from here. any help would be appreciated. i am attaching my gel file, the datasheet for our DDR3 chip, and the updated excel files.

DDR3 help package.zip

over 7 years ago

0 Brad Griffis over 7 years ago

TI__Guru*** 125430 points

So it looks like you're setting SDRAM_CONFIG = 0x61A072B2. That corresponds to CL=10 and CWL=5. Based on page 26 of the datasheet you attached, I was expecting to see CL=6 and CWL=5. So I think you should be setting SDRAM_CONFIG = 0x61A052B2. You need to re-do the leveling after this change (i.e. go back to the seed values).

0 Brad Griffis over 7 years ago in reply to Brad Griffis

TI__Guru*** 125430 points

I also see issues with the way ALLOPP_DDR3_READ_LATENCY is defined (currently 0x0C). The lower nibble can be updated to CL+2-1 = 6 + 2 - 1 = 8. However, you should also set bit 20 (reg_phy_enable_dynamic_pwrdn=1). And I strongly recommend enabling ODT, i.e. reg_phy_rd_local_odt = 2 (full thevenin). So I recommend you update ALLOPP_DDR3_READ_LATENCY to 0x00100208. (Double check my hex math!)

0 cobsonchael over 7 years ago in reply to Brad Griffis

Mastermind 7930 points

the CL i was getting i used the front page which was 11, which is what i was meant to program which i also screwed up. hah. i guess i can't even make mistake right

the read latency i was also basing on my incorrect CL so yeah i see that changing. i think 6+2-1 is 7. we are not concerned about the DDR powering down since we are not on a battery so we always have power. is there another advantage to the DDR powering down beside power savings? i will enable local ODT. so unless you let me know of other advantages for the auto sleep i will set the register to 0x00000207

0 cobsonchael over 7 years ago in reply to cobsonchael

Mastermind 7930 points

making those changes did not affect the board. i made the changes to the CFG and latency values and reran the read/write leveling, power cycled the board and reconnected to the emulator and reran the GEL init script and i still get the same result: writing to 1 byte randomly changes ~6 bytes none of which are the byte i wanted to change.

0 cobsonchael over 7 years ago in reply to cobsonchael

Mastermind 7930 points

in additon here is something else i noticed:

my timing 2 value in the GEL file is 0x26437FDA

when i look at the core registers after loading the gel file the value is 0x2C437FDA. it looks like i am trying to set t_odt to 011b and the register is set to 110b

is this an error in viewing the core registers or is there an error when loading the gel file?

0 cobsonchael over 7 years ago in reply to cobsonchael

Mastermind 7930 points

I went to the memory location for EMIF0 in the memory browser and it does indeed show the wrong value for t_odt. so there is something wrong with the way my gel file is writing to the registers or there is something else wrong with our board/emulation

0 cobsonchael over 7 years ago in reply to Brad Griffis

Mastermind 7930 points

so i guess my GEL file wasn't reloading. i didn't LEAVE the debug mode or reload the gel file after i made my changes. stupid me.

seems to be working at the moment. i ran the DDR transfer check and it passed and so did the edma test. thanks for your help!

0 Brad Griffis over 7 years ago in reply to cobsonchael

TI__Guru*** 125430 points

That's good news! By the way, I recommend using reg_phy_enable_dynamic_pwrdn=1 even if low power is not important to you. That's the setting we've used for all of our validation and testing.

0 cobsonchael over 7 years ago in reply to Brad Griffis

Mastermind 7930 points

well i am not out of the woods yet

i am getting a "Trouble Reading Memory Block at 0x80000000 on Page 0 of Length 0x16e" error when i run my code and try to run things that i thought worked when i stepped over them. i think either i don't have it fully figured out (even though the whole program loads fine) or my very first routine blows up memory somehow. my first routine, fyi, is turning on all the clocks i think i will need

0 Brad Griffis over 7 years ago in reply to cobsonchael

TI__Guru*** 125430 points

You were able to run the leveling code without issues, right? And you put your output values back into the gel file?

One thing that comes to mind is that it might be related to ARM vs THUMB instructions. Can you check the bottom status bar in CCS. You should see "ARM" or "THUMB" somewhere. Can you check that against how your code has been built? Before you execute any code, does it display as expected in the disassembly window (i.e. does it look like normal instructions or do you see a lot of ".word" due to un-decodable instructions)?

0 cobsonchael over 7 years ago in reply to Brad Griffis

Mastermind 7930 points

so it says THUMB at the bottom and in the project properties under Build->GNU compiler->Runtime it says Code State: Compile for ARM

i am unsure if this is the right place to look for this property but the other option is THUMB

what do i do about this?

FYI when i emulate i connect to the branch 'CortexA8" not the "M3_wakeupSS" if that makes a difference

0 Brad Griffis over 7 years ago in reply to cobsonchael

TI__Guru*** 125430 points

One option would be to build your code for THUMB instead of ARM. Another option (the one I recommend trying first) is to go to View -> Registers and then look at the CPSR register. It is an ARM status register and bit 5 "T" controls whether it is in ARM mode or THUMB mode. T=1 means "Thumb". So you will need to clear that bit before you execute any instructions.

0 Brad Griffis over 7 years ago in reply to Brad Griffis

TI__Guru*** 125430 points

Are you loading your program by going to Run -> Load -> Load Program? I am surprised you're having this issue since I see the following inside your gel:

AM335xStartState()
{
CPSR &= ~0x20;
CPSR = (CPSR & ~0x1F) | 0x13;
CP15_CONTROL_REGISTER &= ~0x1;
}

OnPreFileLoaded()
{
AM335xStartState();
}

The OnPreFileLoaded() callback gets invoked any time you load a program. It is calling AM335xStartState() which appears like it should be putting you into ARM state. So I'm not sure why you're in Thumb mode...

0 cobsonchael over 7 years ago in reply to Brad Griffis

Mastermind 7930 points

i am loading code that way and maybe i didn't load the program when i replied before. in arm mode it does the same thing. at this point i can't even do a Run->Go Main. it just starts running and never hits main. when i halt i get the error reading memory. i used to be able to start my program but now i can't even get to main

when i look at disassembly i am seeing ".word" frequently

i do have all the leveling values in my GEL and all the GEL related DDR tests passed also my code loads without issue. after i try to run it though i cannot load code

when i do a reset then a restart it puts me at CACHEDataCleanInvRange() to start. is this normal? i am used to my C6748 taking me to Cint to start

0 Brad Griffis over 7 years ago in reply to cobsonchael

TI__Guru*** 125430 points

Suggestions for your gel file:

1. Move the following lines from OnTargetConnect() to the start of OnPreFileLoaded():

GEL_AdvancedReset("System Reset"); // Reset the board to avoid conflicts with program running from NOR/SPI/SD
GEL_Halt(); // System Reset leaves the core running. Needs to halt it so memory can be accessed
Disable_Watchdog();
AM3352_Model840i_Initialization();

So now your OnPreFileLoaded function should look like this:

OnPreFileLoaded()
{
GEL_AdvancedReset("System Reset"); // Reset the board to avoid conflicts with program running from NOR/SPI/SD
GEL_Halt(); // System Reset leaves the core running. Needs to halt it so memory can be accessed
Disable_Watchdog();
AM3352_Model840i_Initialization();
AM335xStartState();
}

2. Don't use restart! Instead use "Reload Program". You get into all kinds of issues when using restart because you end up with remnants of stuff in the cache, peripherals in a different starting state, etc. You're setting yourself up for lots of problems. Any time you want to restart, instead do a "reload". That coupled with the changes I suggested above will give you a complete reset of the entire chip (and if you've connected the warm reset pin smartly, the entire board). It will then reconfigure the PLLs and DDR, and finally load your code. This is a very robust way to do your development. In general you'll see a lot less "weird" behavior and CCS crashes by doing it this way.

3. Make sure you reload the gel file after you make the changes! ;-)

I'm not sure if this is enough to fix all your issues, but let's start there...

0 cobsonchael over 7 years ago in reply to Brad Griffis

Mastermind 7930 points

ok no restart!

i made the changes and i did reload the gel. it however still will not get me to main. no change

when i halt after letting it run for a while trying to get to go main i get this error
CortxA8: Trouble Removing Breakpoint with the Action "Terminate GEL_Go()" at 0x8006caf0: (Error -1066 @ 0x3332) Unable to set/clear requested breakpoint. Verify that the breakpoint address is in valid memory. (Emulation package 6.0.407.6)

it seems like i get stuck in sysbios routines before i even get to main. i am seeing a lot of cache get level and HWI disable and stuff like that. is this normal execution? what should i be seeing from code load to main?

following it closer it seems that it is stuck in some loop in the startup inside xdc_runtime_Startup_startMods__I

i am stepping through this startup and it seems to hit a few modules twice making me wonder if it is stuck in some infinite loop. the second time i get to ti_sysbios_timers_dmtimer_Timer_Module_startup__E() it goes haywire

sorry for the edit i didn't want to make a new post

0 Brad Griffis over 7 years ago in reply to cobsonchael

TI__Guru*** 125430 points

I suspect there might be an infinite loop if perhaps sysbios thinks the clock to the timer has already been enabled at the PRCM level. That might be the case in a "normal boot" since the boot ROM configures quite a few clocks.

I think we should focus for now on closing out this thread with respect to correct operation of DDR. I think the BIOS issues should be a separate topic. So with respect to DDR configuration:

1. After the gel file configures DDR are you able to maximize a memory window pointing to DDR space (e.g. 0x80000000) and hit the refresh button a bunch of times? If you're seeing anything flash red that indicates that CCS is seeing bits changing which would be bad...

2. Can you poke some random values into various places of memory and refresh a bunch more times?

0 cobsonchael over 7 years ago in reply to Brad Griffis

Mastermind 7930 points

yeah i guess i'm getting carried away here. multiple refreshes at 0x80000000 seem to be stable as does location 0x84000000. i am assuming i have an issue with my project and the DDR is likely fine

Processors

Processors forum

AM335x custom board, DDR3 issues