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++

Programming the EPCS

Altera_Forum
Honored Contributor II
1,112 Views

Hi All, 

We found a problem in the AVALON HAL. We are using a CFI flash from Spansion, when registering the Flash, the code will put the flash into Query Mode several times in a row. This causes the Flash from Spansion to go back into Reset mode, and thus the registration fails. 

 

We have circumvented this, by removing the un-necessay line  

 

(*flash->write_command)(flash->dev.base_addr, 0x55, QUERY_MODE); 

 

However, since the Flash Programming tool, still doesn't work we have opted to create piece of code which will read a firmware off the USB and write it to the flash ( fortunately SRecord files are easy to parse ). 

 

The problem is that since the programming tool doesn't work, we are forced to use the same method to write the EPCS controllers flash/EEPROM/Whatever. 

 

I am uncertain about what functions I should use.  

 

Using the alt_flash_open_dev(EPCS_CONTROLLER); seems to work.. kinda..  

 

I can open the flash, and reading the info also returns the correct information, reading from the flash is also done ok. However when writing, the alt_flash_write(...) function will hang, most of the time. Sometimes it will actually return, and I can proceed. 

 

I may be totally wrong here, perhaps I should use the  

 

alt_flash_epcs_dev epcs_flas; 

alt_epcs_flash_init (&epcs_flas); 

 

functions, but using these functions create a linker error (alt_epcs_flash_init is apparently not being compiled).. 

 

any pointers??
0 Kudos
5 Replies
Altera_Forum
Honored Contributor II
484 Views

Hi all, 

 

I have located the problem, I was using the right functions, but Alteras Avalon code is seriously buggy, as a matter of fact, I am pretty sure the code has not been tested... 

 

Here's the kind of code you'll find, if you dig into the HAL functions 

 

function A( int iCount ) 

char buffer[4]; 

 

int a = 0; 

int b = 4; 

 

while ( iCount >= 0) 

int c = iCount > b : 4 : iCount; 

 

buffer[a] = 0x0a; 

 

a += c; 

iCount -= c; 

 

assume you call A(16), then you will pass the bounds on the buffer, and overwrite the stack, furthermore you will enter an infinite loop. 

 

Now take a look at the alt_epcs_flash_memcmp function in altera_avalon_epcs_flash_controller.c file, you'll see the exact same construction. 

 

This kind of thing makes you wonder.... http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/smile.gif
0 Kudos
Altera_Forum
Honored Contributor II
484 Views

Hi, 

 

I&#39;ve just gone through the code in alt_epcs_flash_memcmp and I can&#39;t see any buffer overflows. 

 

Could you tell me exactly what the inputs to this function are which will cause the buffer overflow please. 

 

I agree that your code is wrong, but I can&#39;t find that code in the HAL. In future please point to the function and line number which you think is buggy. 

 

Thanks,
0 Kudos
Altera_Forum
Honored Contributor II
484 Views

I can shed some light on this issue. There was indeed a bug in alt_epcs_flash_memcmp in the nios 2 1.0 release, which could result in a buffer overrun. The bug fix is present in the upcoming nios2 1.1 release. If you want to patch your HAL code until 1.1 is available, change the following two lines in altera_avalon_epcs_flash_controller.c: 

 

line 145:  

was:  

while (n >= 0) 

change to: 

while (n > 0) 

 

line 154: 

was: 

&chunk_buffer[current_offset], 

change to: 

chunk_buffer,
0 Kudos
Altera_Forum
Honored Contributor II
484 Views

http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/sad.gif Thanks,  

 

I am sorry if I came across as a wise-ass, I was just getting very frustrated.. http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/sad.gif  

 

As I found the bug, it was easy to fix. My point is not that the code contains bugs - most code will contain bugs - but it seemed as if the code had not been tested at all. Just one single run of the code, would have shown that the code was faulty (perhaps you&#39;d have missed the buffer overrun, but certainly not the infinite loop).  

 

Anyhow, fortunately we have access to the source code, and we are able to fix the problems ourselves.
0 Kudos
Altera_Forum
Honored Contributor II
484 Views

Apologies from me as well. I was looking at the 1.1 source code which, as has been pointed out, no longer has the bug.

0 Kudos
Reply