Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Altera_Forum
Honored Contributor I
2,132 Views

On-Chip Memory instruction corruption

We have a design which uses a NIOS CPU whose instruction code is stored in On-Chip Memory. Most of the time everything works however there are times when the code is changed slightly and either the firmware consistently jumps to the beginning of the code or the code appears to freeze. This happens even when we add code that has no functional application to the system (e.g. adding debug lines to the code). We have checked the size of the memory and the size of the code and there is more the ample space for the stack. Also we have compared the contents of the Flash in which the code is stored to the code that is copied into the On Chip Memory and they are identical. 

 

Does anyone have any ideas where we should start our debug ?
0 Kudos
14 Replies
Altera_Forum
Honored Contributor I
49 Views

How well constrained is your project? How fast is your Nios running? Does it all meet timing? By adding the code you're adding are you exercising part of the logic that has a timing issue but not doing so without the extra code? 

 

Cheers, 

Alex
Altera_Forum
Honored Contributor I
49 Views

Dear Alex, 

 

Thanks for your reply. I will check the timing a little more. We are running the sysCLK @100Mhz. We also have a TSE GigaBit design and its clocks within the system as well. I know last time I did some timing analysis I had constrained all the clocks but none of the IO 

 

This problem has occurred when we changed the code at times we added code and times we deleted code.  

 

This on chip memory is dual port. We did so more debug on it. I pulled out the basic signals to the block and started looking at them. In the system we have 3 NIOS processors. The first is responsible for communicating to the the Flash. On start up it holds the CPU1 and CPU2 in reset. It reads the instructions from flash and copies them into the separate on chip memories associated with each CPU. It then 1 by 1 releases each CPU after some system checks. This is the basic outline of the system and power up. I check this powerup sequence and I saw the writes from the CPU0 to the on chip memory of CPU1 while it was being held in reset. Then I also saw the release of the CPU1 reset. So far so good. However after the release of the reset for some reason I saw additional bursts of writes to the on chip memory of CPU1. This is not impossible as there is some handshaking and transfer of data to and from CPU1 to CPU0 for storage and retrieval from the flash. I was worried that maybe there was some sort of corruption to to the instruction code. However when we narrowed down the code of the CPU0 we found that it was a single line of code that didn't really do much. It read a variable from the stack from its own on chip memory added 1 and then wrote the the variable back to the stack. This we doubled checked from he assembly code. We changed the stack and the heap everything except where the code is run from and put it into a completely different on chip memory and this strange effect still existed. Interestingly, the CPU1 appeared to work. When we moved the CPU0 instructions into another on chip memory nothing appeared to work - but that was expected.  

 

Any more suggestions from anyone ? Leads ?
Altera_Forum
Honored Contributor I
49 Views

Timequest say that there are timing violations? (Setup or hold time not met?)

Altera_Forum
Honored Contributor I
49 Views

I checked non of my IO are constrained - but is this really going to matter ? I am now trying a compile with my QSPI Flash "Active Serial Clock Source" reduced down from 100Mhz to 12.5MHz !

Altera_Forum
Honored Contributor I
49 Views

Logic inside onchip memory don't require IO constraints. Could you post your compile report?

Altera_Forum
Honored Contributor I
49 Views

I have uploaded the *.fit.rpt - is the this the report file you were interested ?

Altera_Forum
Honored Contributor I
49 Views

For some reason the upload is not working - which part of the report file are you looking for ?

Altera_Forum
Honored Contributor I
49 Views

Timing reports

Altera_Forum
Honored Contributor I
49 Views

O.K> I uploaded it as a DOC file...

Altera_Forum
Honored Contributor I
49 Views

You have some timing problems: 

 

+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ 

; Slow 1100mV 100C Model Setup Summary ; 

+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------+---------------+ 

; Clock ; Slack ; End Point TNS ; 

+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------+---------------+ 

; clock100MHz ; -5.337 ; -1273.828 ; 

; rgmii_125_tx_clk ; -1.041 ; -4.946 ; 

 

On clock100MHz and on rgmii_125_tx_clk you have timing violations (very strong violation on clock100MHz). It is normal that your design does not works.
Altera_Forum
Honored Contributor I
49 Views

I have worked on the timing and got the violations down a lot - I have posted the report. The remaining are violations don't appear to be significant (at least to the area of the design that I am working on) 

 

I check the design and it is still showing this bug ??????
Altera_Forum
Honored Contributor I
49 Views

You have violations yet

Altera_Forum
Honored Contributor I
49 Views

This problem has occurred when we changed the code at times we added code and times we deleted code.

Altera_Forum
Honored Contributor I
49 Views

My 2 cents; If you suspect a timing problem, try slowing down the clock and see if the problem persists.

Reply