Nios 1 to Nios 2

[Altera_Forum]

Up till now I have only played with NIOS2. I have many NIOS1 (3.01) designs out in the field and it has served me well. 

 Problem. I developed a small dev board running NIOS1 with 128KB SRAM, 1MB Flash and CS8900 LAN. It works perfect with NIOS1. Then I tried to port the design to NIOS2. I have to use legacy mode for several reasons (for one, too many units in the field uses it). The software seemed to work perfectly. When I tried to flash it to 0x140000 it gave me an errors. Tried to use GERMS to write a word or erase and nothing. I eventually gave up and produced another product based on NIOS1 (hey, it works).  During the development of the newer product I decided to try NIOS2 again (and again it was designed to only use legacy mode). This time I started with the CS8900. No comms. Hmmmm? Tried to write to Flash with the same problems. I could read it but not write and erase.  So I decided to test my new code on the old board on NIOS1. Both the Flash and CS8900 routines worked perfectly. Reloaded NIOS2 and recompiled. No LAN and no Flash. You can read but not write. Checked the relevant write signals on the FPGA and got nice pulses. Eventually I decided to stay with NIOS1 and got the new board up and running in 1 hour.  Yesterday I started on a new project. The client needs low CPU bandwidth but also requires a 2 mbit/s data link, all on a 1C3 144 pin device. This is ideal for NIOS2. He insists on the simple RS232 interface as he personally hates fancy IDEs and JTAG cables. So back to legacy mode, that sits really well with me.  So I thought it might be that something slipped in. I did a virgin install of Q4.2 and Nios2. Started a project from scratch. The SRAM works like a charm but the Flash still has exactly the same problem, read but no write. Software runs perfectly from SRAM, but you cannot write to flash from both the GERMS monitor or from code.   The implentation has the following Nios2/e, 128kb SRAM, 1MB Flash, Tri state and 1x UART running at 20 MHZ. I also tried a custom CFI with timings in the range of 4000ns. Reads perfectly, but no writes and erases.   Even the NIOS1 design(working) ported to NIOS2 does the same thing. The same problem occured on a 1C6 240 pin design with 32MB of SDRAM.   Any suggestions?   VictorS

[Altera_Forum]

Did you try to program the flash manually, not through the GERMS but with a simple stand alone program that you write yourself? Maybe this can be a help to understand the problem. At the end you can convert that little program to a home-made boot loader. 

  I use also legacy mode, but not with the altera provided lib. I only use the excalibur.h file to now where the peripherals are. I now it is some more work in the beginning, but it can be faster to detect problems like this.

[Altera_Forum]

It looks like I can read from both the Flash and CS8900 but cannot write to them. 

 Like I said before I have checked with a scope to see if there is signal and it looks OK. Will quickly try again with known working Flash code.  I have thought that NIOS2 jumbled the address or data lines up. Garbage put in a certain way will come out exactly the same way on RAM. Flash however needs a specific code to write and erase data. But the data written by NIOS1 is the same as read by NIOS2, meaning that the address and data lines are correct.   Will check and come back  VictorS

[Altera_Forum]

--- Quote Start ---  originally posted by svhb@May 9 2005, 03:45 AM did you try to program the flash manually, not through the germs but with a simple stand alone program that you write yourself? maybe this can be a help to understand the problem. at the end you can convert that little program to a home-made boot loader.   i use also legacy mode, but not with the altera provided lib. i only use the excalibur.h file to now where the peripherals are. i now it is some more work in the beginning, but it can be faster to detect problems like this.  --- Quote End ---     Tada...and the winner is.....  Something went funny with NIOS2. Ripped out some old code, modified AMD.c file, and wrote some erasing and writing code. NOT WITH THE ALTERA PROVIDED LIB. Guess what? it works.  So GERMS and the LIB are stuffed.    So rewrite GERMS (because I need it) and still figure out why the CS8900 doesn't want to work.  Will keep you updated and will post my code when complete  VictorS    Now the real question is how many other people in the same situation has got it working?

[Altera_Forum]

Man!!! Who wrote GERMS for NIOS2 ??? Wrong codes for Erase and Write, byte ordering problems. No wonder it wouldn't work. Maybe I just got the code from the bottom of the bucket? 

 Who ever is responsible for the code please feel free to PM me and I will email you a copy with my changes. It is still in a dreadful state and needs to debugged. If anybody needs it urgently also PM me.  VictorS

[Altera_Forum]

Myaybe they put some bugs in to prevent people using the legacy mode of developping ... :-)

[Altera_Forum]

Well it is almost sorted out on this side.  

 One of the reasons why I don't use the IDE is because my clients all know RS232. The cable is simple and the interface reminds all of a telnet session. Many times the NIOS board is so hidden away, far, far down in a box with the operator sitting somewhere on the outside, like in a military tank application. So far I have had bad experiences with JTAG cables of 5 meters and usually the ByteBlaster must be within centimeters from the FPGA. With serial it is slower but much more flexible. Another reason to use the serial cable is that a MAX232 contains 2 channels. On many applications I have 2 windows showing diagnostic data. But many prefer to step through software. If you cannot program then it is your problem. I like to code, download and run. Been programming since 1981 and the more complex the tools the slower the development (in the beginning it seems faster).

[Altera_Forum]

Hi, 

 I also hate stepping through code. Especially because I tried it when I first openend the box with NIOSI a few years ago and it was not working.  I can imagin it is fancy to do on small simple main loop programs, but as soon as things get complicated, ... Especially if a machine is running, I don't want my critical code to stop if there is a breakpoint.  I used some stepping on a PC application, but this is so different than real world applications.  Stefaan.