Forum Discussion
Honored ContributorNios II hanging/crashing on PIO write?
I'm using a DE0-Nano board with a design which includes a NIOS II processor with a PIO module to flash the board's LEDs.
No problems there - processor works, LEDs flash, jolly good. But, I then did the following: - Added a second PIO, 24-bit width output-only, and connected this to a custom hardware module in the project bdf - Added a third PIO, 1-bit width input-only, with interrupt enabled, and connected this to a custom hardware module the project bdf (a clock signal). I made no changes to the NIOS II code, and so I tried to build, download and run the program just to make sure everything still worked. Sure enough, it doesn't. In Debug mode, I see the NIOS II processor seems to lock up the moment it gets to any IOWR routine to write to the PIO for the LEDs (again, there is no code referencing the other PIOs, beyond what is generated by the BSP). What could be causing the CPU to lock up? The lack of an ISR for the interrupt I just created? I thought the interrupt was disabled until I registered it.16 Replies
Altera_ForumHi again,
Further to my last post, I've found the original code works properly if I leave the new 24-bit and 1-bit PIO modules unconnected. As soon as I connect either PIO to its relevant custom hardware module in the block schematic, the code will no longer function. Any suggestions? There is precious little on the web about using multiple PIO modules in a NIOS II design. Presumably because they usually just work, haha. :)- Altera_Forum
Several ideas:[list][*]the address mapping changed and the software you compiled is still using the old address map that is no longer valid
[*]your new peripherals are using a clock that isn't running and this locks the Avalon bus [*]the new compiled FPGA project doesn't meet timing requirements[/list] - Altera_Forum
Is this a Qsys or SOPC Builder based design? If it's Qsys then perhaps you are writing into space due to a mismatch between the software and hardware (Qsys is less forgiving when it comes to writing into space). I recommend putting the system ID peripheral into your system to help catch some of the mismatches Daixiwen mentioned.
I would also try simulating the design. That should give you more insight into what is causing the issue. Last but not least, how much space do you have left for the stack and the heap? Could be that you were on the hairy edge of running out and the code change with the new PIO put you over. - Altera_Forum
I'm also having a very similar issue to this. The while(1) loop within my program runs perfectly for the first iteration, but then just hangs on the IOWR_ALTERA_AVALON_PIO_DATA macro the second time around.
Any ideas why it would work the first time but not the second? I'm not changing any base addresses or anything. Incidentally, when the system hangs, I have to redownload the .sof onto my board for it to run again, otherwise I get an error saying "'Launching [project name] Nios II Hardware configuration' has encountered a problem. Downloading ELF Process failed". - Altera_Forum
Actually what you are describing might be something different. If your while (1) loop is tight it could be the debugger having problems stepping through it. I'm not sure what actually happens when that bug is reached that I'm referring to but the symptoms you described sound just like it.
- Altera_Forum
Thanks BadOmen, I think I sorted it out anyway. As my PIO out was running with a 50kHz pll clock, compared to my 50MHz system clock, I think the system was probably waiting for 1000 iterations before it wrote the data (would explain why the first one was output fine, as the two clocks would then have been in sync). I've since amended the system to both run off the same clock and the data is output fine. Although, I have a horrible feeling that I'm gonna get a 1000x repetition of each of the values I'm trying to read...
- Altera_Forum--- Quote Start --- Thanks BadOmen, I think I sorted it out anyway. As my PIO out was running with a 50kHz pll clock, compared to my 50MHz system clock, I think the system was probably waiting for 1000 iterations before it wrote the data (would explain why the first one was output fine, as the two clocks would then have been in sync). I've since amended the system to both run off the same clock and the data is output fine. Although, I have a horrible feeling that I'm gonna get a 1000x repetition of each of the values I'm trying to read... --- Quote End --- I am also having the same issue as that of el07...but my system clock and the PIO clock are the same.Still i have this problem.What can be the reason for the Nios hanging when attempting to write a PIO.?
- Altera_Forum
Make sure to use the HAL driver libraries for the PIO instead of accessing it directly. If you are accessing it directly you might be writing to the wrong location causing the master to lock up.
- Altera_Forum
I am using the altera_avalon_pio_regs.h files for the write operation macros.Still i got the problem of locking up.
- Altera_Forum
Are you passing in the base address of the PIO defined by system.h? If so I would look at the base address macro in system.h and compare it against what is shown in the Qsys UI to make sure they match.
