NRugg
Occasional ContributorJoined 5 years ago
User Profile
Occasional Contributor
User Widgets
Contributions
Re: Best Practice for Editing Ipport.h options
I have found the solution to this issue! It turns out the file I needed to edit was a located at C:\intelFPGA_pro\19.4\nios2eds\components\altera_iniche\UCOSII\src\h\nios2\ipport.h Note that the file is not called "ipport.h_h" like the documentation suggests. So for anyone else looking for this same solution, the process goes as follows: Find the ipport.h file specific to your target system. For me this was located at the above path Note that this ipport.h will not be part of your project or BSP. Rather it will be part of the quartus install Make desired changes to ipport.h located in your target system directory Save and close the file Open up NIOS II Eclipse Right click bsp >> Nios II >> Generate BSP Clean and build project Your desired ipport.h changes will now be reflected in the ipport.h file included in your BSP.1.2KViews0likes0CommentsRe: Best Practice for Editing Ipport.h options
I've found a couple more breadcrumbs but no direct instructions for how to accomplish this. In case this sheds some light on the situation, here is what I've found. This documentation comes from the NicheStackRef 2.2 The IP Port File: ipport.h_h Before you compile the portable TCP/IP stack files you should create a version of the file ipport.h_h that is appropriate for your target system. An inspection of the NicheStack source code will show that many of the C language source files include a file named ipport.h . ipport.h is intended to contain not only the IP layer's port dependent definitions, but all the architectural definitions for all the IP related code. CPU architectures (big vs. little endian), compiler idiosyncrasies and optional features (DHCP, multiple interfaces, IP routing support) are controlled in this file. ipport.h is one of the target system include files that are copied to the h directory and thus should not be edited directly. See the section titled Target System Include Directory /h for instructions on how to deal with files of this type. This section outlines the basic contents of ipport.h . Remember, the modifications described in this section should be made to the file named ipport.h_h that exists in your target system dependent directory, not to any file named ipport.h . Changes that you make directly to ipport.h WILL BE LOST the next time you execute make because they WILL BE OVERWRITTEN with the contents of ipport.h_h . Then the following from the same documentation 1.4.5 Target System Include Directory /h Some aspects of a particular target system cannot be easily localized into a single source code directory. These are represented in include files that are included by source files contained in both target system independent and target system dependent directories. ipport.h_h , which is discussed in greater detail later, is the most widely included example of files of this type but there are others. Different versions of these target system include files are appropriate for different target systems. Therefore each target system dependent directory contains a set of these files that is appropriate for that specific target system. For example, the dosmain directory contains a version of ipport.h_h that is appropriate for 16 bit real mode DOS targets and the net186 directory contains a different version of ipport.h_h that is appropriate for Net186 board targets. In order to avoid compilation problems that could be introduced by the presence of multiple include files with the same name in the same source tree, these target system include files, as they exist in the target system directories, are named using the file name suffix .h_h instead of the conventional .h . For development environments using "make" or a similar utility, the makefile in each of these target system directories should copies the .h_h versions of these files from that target directory to a directory named h , changing the extension from .h_h to .h in the process. Thus when the C compiler encounters a directive to include, for example, ipport.h in a source file, there is only one instance of ipport.h in the source tree and therefore the same ipport.h will be included by each source file that includes it, independent of the include search path that has been specified to the compiler. This scheme has some ramifications for porting engineers. The principal one being that if, during the course of a port, it is found to be necessary to modify one of these target system include files, the place to make the modification is NOT in the .h version of the file that resides in the h directory, but in the .h_h version of the file that resides in the target system dependent directory. All files that end up in the /h directory should be considered to be transient files like object files. No modifications should be made to them directly. Modifications made to the .h include files that reside in the h directory WILL BE LOST. For example, if you were porting the stack to an AMD Net186 target system and found it necessary to modify a defined constant in ipport.h , the file in which to make the change would be /net186/ipport.h_h , not /h/ipport.h . This documentation suggests that I edit the ipport.h_h in my target system dependent directory. However the only other version of ipport.h_h I've found on my computer lives in the quartus install path. Editing this file has no effect on the ipport.h that gets included in my project. So my question becomes. Where can I find this ipport.h_h file?1.2KViews0likes1CommentBest Practice for Editing Ipport.h options
I'm curious what the accepted best practice is for editing options in ipport.h My understanding is that all files in the BSP (including ipport.h) are auto generated when you generate a BSP. It's also my understanding that you should never manually edit these auto-generated files because all changes will be overwritten anytime you re-generate the BSP. In NIOS documentation, it states several times that we can edit options in Ipport.h by adding or removing #defines and changing values. These two things seem to compete with each other. So my question is what is the accepted best practice for editing options in Ipport.h?Solved1.3KViews0likes2CommentsRe: Quartus Prime Programmer - Where is the EPCS Flash Tool?
I've found a way to flash NOIS to our embedded target. Here's how I did it for anyone else running into this same issue. The Short Version: Build project, convert resulting .elf to .hex. Then convert this .hex to .jic. Then use Quartus Programmer to flash .jic onto the board. The Long Version: Build your project (this creates a .elf as output) Right click project in eclipse > Make Targets > Build > mem_init_generate mem_init_generate creates several .hex files. Each for a different target memory device. Select the one which matches your target memory device (e.g. mine was generic_quad_spi_controller2_0.hex) Open Quartus Convert Programming File Tool Set the following options: Programming File Type: .jic Configuration Device: <Select_Your_Target_Memory_Device) Mode: <Select_Your_Target_Mode> Click Flash Loader >> Add Device: <Select_Your_Target_Device) Click Add Hex Data: Add hex file created in step 2 Click Generate Close Convert Programming File Tool Open Quartus Prime Programmer Add File > Select .jic created in step 5 Check 'Program / Configure' & 'Verify' Click 'Start', NIOS code will be flashed to the target Enjoy!1.7KViews0likes0CommentsQuartus Prime Programmer - Where is the EPCS Flash Tool?
So recently we have upgraded from Quartus 16.1 to Quartus 19.4. In 16.1 we have access to the NIOS II Flash Programmer (NIOS II > Flash Programmer) In 19.4 when we press this same button a message appears stating the following: "The NIOS II Flash Programmer has been merged with Quartus Prime Programmer. Please refer to the Quartus Prime Pro Edition Handbook for more details on flash programming" I've also seen notes in Embedded Design Handbook stating: "The nios2-flash-programmer has been replaced by the Intel Quartus Prime Programmer flow for EPCS". Can anyone tell me where in the Quartus Prime Programmer one can access tools for flashing EPCS devices? I've looked through the whole tool and found nothing. To add to that, I haven't been able to find any documentation as to how one would use this new paradigm of flashing EPCS with the Quartus Prime Programmer. Several places it says to use this new path, but no instructions on how to access it or use it. If anyone could point me in the right direction that would be super helpful!Solved1.8KViews0likes2CommentsRe: Remote Update IP - How to Debug Reconfiguration Issues
Hi all, I've since resolved this issue. I believe the root of the issue was that I wasn't doing bit swapping as I thought during my experiments. Once I grabbed the right file, and bit swapped the payload, I was able to confirm that the load from .jic and .rpd were binary equivalents to each other. At this point, I was able to succeed in a reconfiguration event. Note: The .rpd that finally worked was created for an EPCS128, even though I am using an EPCQ128A flash memory device. It turns out in my use case (although not every use case) this file format works just fine.2.4KViews0likes1CommentRe: Remote Update IP - How to Debug Reconfiguration Issues
Any thoughts on this? I've tried every file type I know how, still with no luck. I made sure to generate the .rpd file using a version of Quartus that supports EPCQ128A I've tried both big and small endian versions of the above .rpd file I made sure to bit swap every byte before writing it to flash memory I can write and read back the memory contents of EPCQ128A accurately (aka confirmed data is getting written properly)2.4KViews0likes0CommentsRemote Update IP - How to Debug Reconfiguration Issues
System: Cyclone IV NIOS II Soft Core Processor EPCQ128 A used for holding fabric images Programming file = .rpd (each byte bit swapped before writing to flash per documentation) So in our system, we have an EPCQ128 A which houses 3 images. A factory image, and two application images which live at 0x600000 and 0xB00000 offsets respectively. I am able to talk with the Remote Update IP effectively. I can trigger a reconfiguration event (which fails), change the boot address and read the status registers. However, any reconfiguration event fails, and falls back to the default (factory) image. When this happens, I read the RU_RECONFIG_TRIGGER_CONDITIONS register, I get a value of 0x4 which indicates "Bit 2—nstatus_source: nSTATUS asserted by an external device as the result of an error" There is no further description of this error, and I'm not sure how to debug this. What exactly does this error mean, and how do I go about resolving it? Am I using the wrong programming file? (Some documentation says .rpd others say .rbf)Solved2.4KViews0likes5CommentsRe: NIOS II - Hanging on ECPQ / SPI initialization
Thanks for your time, but I was actually able to find the solution to this recently. As it turns out, the issue was entirely configuration related. We added the EPCQ IP to the build, but forgot to actually flash the chip with the new fabric image. So we were trying to access EPCQ registers but the fabric image didn't know how to handle it. So if you see this issue, make sure you have the latest and greatest fabric flashed onto your device! This was entirely the source if my issue.1.2KViews0likes1Comment