- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
So a lot of typing for one question:
Did I find a bug or is there an easier way to propagate changes in the .sopcinfo into your BSP and on into the application? Came across this as I was bringing up my external SDRAM. Not sure if it is my ignorance or a real bug I need to report. I've checked the errata at ltera.com/literature/rn/rn_nios2eds.pdf and did not see it. Using Altera 10 with the latest service pack. Defined a really simple soft processor with the minimal stuff to use the Eclipse environment. I've got a NIOS F processor, on-chip memory, Jtag UART, External SDRAM (whose timing I manually entered), sysID, and system timer. 1. Generate the system in SOPC builder. 2. Compile the sof in quartus and load it in hardware. 3. Open the NIOS Eclipse tools and right click in the project explorer and create a new "NIOS II Application and BSP from Template" 4. Compile the application and download. Software works and runs just fine but I am getting ram errors as I test my external RAM. 5. Return to SOPC builder and change some timing characteristics for the system and regenerate the .sopcinfo. 6. Recompile and load sof in quartus. 7. Here's my problem: It is almost impossible to get the application to correctly regenerate the BSP and use the regenerated BSP. I can make clean on both the project and the BSP, go into BSP editor and click "generate", and the build. Everything builds just fine but when I download, it complains that the sysid on the hardware is newer than the sysid I built my application with. If I delete the application and BSP and then recreate it, it works. I did find an annoying workaround that is less work than recreating the entire project every time the BSP changes. Create another "dummy" BSP in the workspace. When you regenerate the BSP, pull up the project properties for your application, select "NIOS II application properties", change "BSP project location" to your "dummy" bsp, hit apply, then change it back to the one just regenerated. That was the only way I could get it to "take" an updated BSP. To me this says that the BSP project is correctly updating but the application somehow is not "seeing" this change until I switch BSPs. Anybody seen this or have a better way? DavidLink Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The IDE caches the sysid, somewhere near what is displayed when it fails there is a button to 'refresh' the sysid.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The more I mess with this, the more I am convinced it is a bug. If I just regenerate my NIOS, this causes my SYSID and Timestamp to change. I cannot find any way to get the BSP to re-read the .sopcinfo file unless I go into the BSP editor and make some other change by hand then re-generate the BSP. Oh well, once I get the hardware shaken out I will probably move to Linux anyway so I will live with it for now.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Have you tried to delete the Launch Configuration first and create an new one? Or to refresh "Target Connection"? (Both under "Run Configurations...")
This workaround is described in the Errata-Sheet for an other "Spurious System ID Mismatch Error". Maybe this works in your case as well. Philipp- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dude, you have amazing timing. I've been fighting the an error that sounds a lot like the "Spurious System ID Mismatch Error" and for some reason I forgot to check the errata for that. Then you come reply to an old thread from me with a solution to my new problem. Thanks!

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page