help: niosII and pof/sof

Using a .sof is easier during development because you don't have to program the flash.

Do you have a usb blaster connected in JTAG mode with the FPGA? Is the FPGA detected correctly by the Quartus programmer? Did you enable the JTAG debug module in the Nios CPU?

Using a .sof is easier during development because you don't have to program the flash.

Do you have a usb blaster connected in JTAG mode with the FPGA? Is the FPGA detected correctly by the Quartus programmer? Did you enable the JTAG debug module in the Nios CPU?

-------

Here's some background - this board has been used for something else, but we are considering using it for a different application. This would be our first Nios based design. The application that currently uses the board was developed in Quartus and can be programmed to the Serial Config device using the pof file and a USB Blaster.

I did a bit of digging yesterday and found a document on the altera web:

../literature/hb/agx/agx_52011.pdf

See pages 42 and 84 for the difference between configuration using a serial device (in this case EPCS64) and JTAG.

After finding that, I dug out the board schematic and found the following:

MSEL[3..0] = 1000 (as expect from the Figure 11-15 p.42 in the pdf)

nSTATUS, nCE, DCLK, CONF_DONE, nCEO, nCONFIG, nCSO, DATA0 and ASDO are also wired as expected.

-> no surprise here. As I mentioned, the part can be programmed using the USB blaster in Active Serial Mode.

However, when I compare my PCB schematic with Figure 11-35 (p.84) I find the following:

TDO - no connect on my PCB.

TDI - pullup to VCC on my PCB

TMS - pullup to VCC on my PCB

TCK - pulldown to GND on my PCB

TRST - no connect.

All of this leads me to the conclusion that I cannot use the jtag uart for debug. I'm not even certain that I can use an sof file with this board configuration.

Thoughts?

-----------------

I'd still like to use this board for a nios based project.

If you can't load the fpga over JTAG, I doubt the JTAG debug will work either.

If you remove the JTAG debug module you might find that the nios cpu actually comes out of reset - it will exectute the EPCS boot code.

Might be worth arranging to put some simple code (eg LED flashing) in some other internal memory at the reset address to prove you can get the nios running before attempting the EPCS code bootstrap.

If you have anything you can use to act as an avalon master it will make software debug somewhat easier! We used an 8-bit PIO slave with a few address bits writing each 32bit address/data as 4 8-bit values, you could use a serial port 4bits command + 4bits data to have the same effect!

True you can't use .sof files without the JTAG connection. You won't be able to use the nios downloader or nios programmer either to run your software.

What you will need to do is to compile your software, convert the .elf to a flash file and put it in the flash with the Quartus programmer. When converting to a flash file you will need to provide the fpga design so that the .elf file is mapped just after the FPGA image on the flash.

Ensure too that the CPU has his reset vector set to the EPCS controller so that it will load the software when it boots.

If you have two spare pins you can use them as a serial bus, with a UART core. This can ease debugging and communication with the CPU.

Thanks dsl

I tried your suggestion, but but was unsuccessful: Here's what I did -

1.) create basic nios2 system

- OnChip ROM, 32K - initialized from onchip_rom.hex

- OnChip RAM, 32k - initialized from onchip_ram.hex.

- nios II/f, data cache disabled, no JTAG debug support.

--- reset vector pointed to address 0x0 of ROM

--- exception vector pointed to address 0x20 of ROM

--- break vector pointed to address 0x20 of ROM

- sysid block

- system timer block

- 1 PIO connected to a 10 pin debug header I have on board.

2.) Use Eclipse SBT to create a basic application which infinitely loops just incrementing an 8 bit count and does an AVALON_PIO_WR to the PIO block. (there's a usleep(10000)) at the bottom of the loop.

3.) compile Nios SBT

4.) make mem_init_generate to create onchip_ram.hex (all zeros) and onchip_rom.hex, from the elf and then add the mem_init.qip file to my QII project.

5.) build the system in QII

6.) download the .pof file to my device.

7.) attach a logic analyzer to my debug pins (PIO) and they're not toggling.

--------------------------------

going to keep working on this. I really need to get NiosII working on this board.

Hi Daixiwen,

I'll give your method a shot too. I need to do a little research on your suggestion. I've not used the EPCS core nor have I programmed the flash using anything besides the pof created by QII.

I'd just use a 'for' loop for the delay.

If you are using the ide stuff to build you code, yiu might want to make you code be alt_main() - cuts out a fail amount of extra code.

For absolute minimal support, you just need to set %sp and %gp prior to jumping to the C function. I set them up in the linker script to save having another file.

--- Quote Start ---

True you can't use .sof files without the JTAG connection. You won't be able to use the nios downloader or nios programmer either to run your software.

What you will need to do is to compile your software, convert the .elf to a flash file and put it in the flash with the Quartus programmer. When converting to a flash file you will need to provide the fpga design so that the .elf file is mapped just after the FPGA image on the flash.

Ensure too that the CPU has his reset vector set to the EPCS controller so that it will load the software when it boots.

If you have two spare pins you can use them as a serial bus, with a UART core. This can ease debugging and communication with the CPU.

--- Quote End ---

Daixiwen,

I seem to have the same problem with the SBT Flash programmer - it requires that a jtag debug core be present in the device design. (Table 1-1 of the Nios II Flash Programmer User Guide.)

Recall that my jtag signals are not connected: (TDO,TRST both NC, TDI,TMS both Vcc, TCK GND)

The EPCS Controller core documentation says the the boot loader from the EPCS core copies the image to ram, then changes the program counter to transfer control to the program in RAM.

Can't I just bypass the loader and start executing code straight from an OnChip ROM?

I have spare pins and I/O. Adding a UART core is a great idea. Once I get the cpu to boot and execute my simple program to count out a PIO interface, UART willl definitely be one of the first things I add. (I love printf debug!)

Yes, you can get the nios to execute code that is set in on-chip memory as part of the fpga initialisation - that is what the epcs boot code does.

For debug. I like to be able to read memory blocks out of embedded systems and do a hexdump display on some terminal. Repeated displays can give a good insight into what the code has done - and without affecting the control flow/target code as much as doing actual prints (but they are useful as well). I've written far too much comms protocol code where you can't stop on breakpoints (because the far end won't wait) and there aren't enough cpu cycles for printf.

This is a minimal linker script that can be used to build images without any of the Altera initialisation or library code. I think it works - but is a cut down copy of one that does work so might have typos.

I put the code in 0..64k (but avoiding 0), data in 64k..128k, and io just above 128k. %gp is set to cover data and io (so data starts a bit higher up).

The low 256 bytes of data memory are used as the stack, the very bottom will be used to save the registers on any exception. I don't actually use any stack - except that gcc insists on saving registers on entry to a function marked 'noreturn'.

OUTPUT_FORMAT("elf32-littlenios2")
OUTPUT_ARCH(nios2)
MEMORY
{
        code (x) : ORIGIN = 0x4000, LENGTH = 8k
        data (rw) : ORIGIN = 0x14000, LENGTH = 8k
}
/* Memory (and some io) from 0x14000 to 0x23fff is accessible from %gp */
_gp = 128k - 16k;
SECTIONS
{
    /* code */
    code : {
        /* Set %gp then %sp and %et from %gp */
        LONG(26 << 22 | ((_gp + 32768) >> 16) << 6 | 0x34)
        LONG(26 << 27 | 26 << 22 | (_gp & 0xffff) << 6 | 0x4)
        LONG(26 << 27 | 27 << 22 | ((stack_top - _gp) & 0xffff) << 6 | 0x4)
        LONG(26 << 27 | 24 << 22 | ((reg_save - _gp) & 0xffff) << 6 | 0x4)
        LONG(c_code << 4 | 1)   /* jmpi c_code */
        . = 0x20;
        /* Save all registers relative to %et */
        LONG(24 << 27 | ((1 << 22 | 4 << 6) * 0) | 0x15)
        /* Repeat changing reg number - total 32 lines until */
        LONG(24 << 27 | ((1 << 22 | 4 << 6) * 31) | 0x15)
        /* Save control registers 7 (exception cause) and 12 (badaddr) via r2
         * as registers 32 and 33. */
        LONG(2 << 17 | 0x26 << 11 | 7 << 6 | 0x3a)
        LONG(24 << 27 | 2 << 22 | (4 * 32) << 6 | 0x15)
        LONG(2 << 17 | 0x26 << 11 | 12 << 6 | 0x3a)
        LONG(24 << 27 | 2 << 22 | (4 * 33) << 6 | 0x15)
        LONG(. << 4 | 1)        /* loopstop */
        *(.code)
    } >code
    data : {
        reg_save = .;
        . = . + 256;
        stack_top = .;
        *(.data)
        *(.rodata)
    } >data
    /* Overlap unexpected sections with code to generate an error */
    unwanted 0x4000 : { *(*) }
}