Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
Announcements
FPGA community forums and blogs on community.intel.com are migrating to the new Altera Community and are read-only. For urgent support needs during this transition, please visit the FPGA Design Resources page or contact an Altera Authorized Distributor.
12748 Discussions

Weird heap access in NIOS w/DDR2 memory

Altera_Forum
Honored Contributor II
1,552 Views

Guys, I have a very strange behavior of my system. I’m very close to get crazy, because I don’t find the reason now for 2 days. Well, the situation is: 

 

Altera C3120 dev. board. Bottom DDR2 is set for ext. memory, with HP controller (the old, not the II.one) I use NIOS IDE, not Eclipse. In the system lib settings I set everything to ON_CHIP_MEM, except the heap what is set to DDR2_MEM. The C++ code is very simple: 

 

1 byte i, j = 0xFF; 

 

2 source_ptr = (byte*) new byte ; 

3 dest_ptr = (byte*) new byte ; 

4 memset(dest_ptr,0xFF,TRANSFER_LENGTH); 

5 for (i = 0; i < 10; i++) 

6 source_ptr = j--; 

7 memcpy( dest_ptr, source_ptr, 10);  

8 for (i = 0; i < 10; i++) 

9 printf("%2x %2x\n", source_ptr, dest_ptr[i]); 

 

10 delete dest_ptr; 

11 delete source_ptr; 

 

Byte is derived from unsigned char (8 bit), btw. TRANSFER_LENGTH is 10 bytes. 

 

Line# 9 prints wrong result. So I started to debug. 

 

source_ptr has the address 0x00000008 

source_ptr has the address 0x00000070 

 

After line# 6 I get this, what is absolutely not good. 

 

Address 0 - 3 4 - 7 8 - B C - F  

00000000 FBFAF9F8 00000000 00000000 00000000  

00000010 00000000 00000000 00000000 00000000  

00000020 AAAAAAAA 00000000 00000000 00000000  

00000030 AAAAAAAA 00000000 00000000 00000000  

00000040 AAAAAAAA 00000000 00000000 00000000  

00000050 AAAAAAAA 00000000 00000000 00000000  

00000060 00000000 00000000 00000000 00000000  

00000070 FFFFFFFF 00000000 00000000 00000000  

 

After line# 7 I get totally illogical values at 0x70 and moreover the values of 0x8 – 0x70 gets changed too – for no reason. Of course dumping the line# 9 means absolutely bad results. 

 

First idea would be that maybe the HP controller causes this. BUT NOT, because if I type different values directly by hand in the memory dump window, that works ok. This means everything is ok with the HP controller and even the pin assignments are correct (what I checked many times, btw). The second idea should be that something is wrong in the C code (I have no clue what should be wrong in a simple code). Anyway, if I set the heap to ON_CHIP_MEM everything works fine, here is the result: 

 

See from the address of 0x0803f58 and from 0x0803fc0: 

 

Address 0 - 3 4 - 7 8 - B C - F  

08030F50 00000000 69000000 FFFEFDFC FBFAF9F8  

08030F60 F7F60208 00100408 00000000 00000000  

08030F70 00000000 00000000 00000000 00000000  

08030F80 00000000 00000000 00000000 00000000  

08030F90 00000000 00000000 00000000 00000000  

08030FA0 00000000 00000000 00000000 00000000  

08030FB0 00000000 00000000 00000000 69000000  

08030FC0 FFFEFDFC FBFAF9F8 F7F6FFFF FFFFFFFF  

08030FD0 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF  

 

I’m loosing my hair! Does anyone has some idea about this issue?
0 Kudos
3 Replies
Altera_Forum
Honored Contributor II
570 Views

Could be a burst size problem. Is burst enabled on the CPU? If yes try to disable it and see if it works better.

0 Kudos
Altera_Forum
Honored Contributor II
570 Views

I would simulate the system and look at the data being presented to the SDRAM. Also if you are not using somewhat recent tools like 9.0 or 9.1 you could be seeing the bug I found in the HPDDR controller. I can't remember what version has the fix but the controller didn't declare itself as a burst wrapping slave port which could lead to a functional failure depending on what kind of bursting master you hook up to it.

0 Kudos
Altera_Forum
Honored Contributor II
570 Views

Thank you guys! You were trying to be helpfull, but it seems the case was a bit different. By accident I could find the problem, the solution is a bit strange: 

 

So this is a 3C120 dev kit, one AC-DC PS is bundled with it. Replacing this original adaptor solved the problem. The original one got faulty and sourced only 8 Volts. This caused that the board was working perfectly - it looked like to do - misleading me. Only when I wanted to use the DDR2 I got problem. 

 

However this is interesting. This board uses Linear Technology stabilizers. So how is possible that if a part needs max 3.3 Volt (DDR2 1.8 Volt) it cannot work if the stab IC gets "only" 8 Volt??? If I design something, I try to have the lowest source voltage as possible. In such case for example I would source max. 5 volt. Agree? 

 

Thanks again!
0 Kudos
Reply