I have a design working on CycloneV Soc (Atlas/DE0 Nano Soc board), that has:
- a linux environment on the HPS side. It does nothing at the moment.
- On the FPGA side, a QSys-generaatd project including
- a set of UARTs, based on Altera UART
- a NIOSII/e core using OnChip memory for code & data.
The NIOS2 reads incoming data over the UARTs, and stores the received byte in local NIOS memory (=onchip memory), and everything works fine.
Now, I added a mSGDMA core in the QSys project, with the intent to let the NIOS2 use it to push received data to HPS memory (DDR3) via the FPGA-to-Host bridge.
Just adding this mSGMA component and connecting it (clock, reset, csr on NIOS data bus, source on onchip memory, and destination on F2H bridge of the HPS), without accessing/using this mSGMA core, results in my earlier NIOS code failing: somehow the main loop gets stuck on the "read" operation on the UART, that was working just fine before the mSGDMA core was added.
I have re-generated the preloader, as well as the NIOS BSP, rebuilt everything, to no avail.
If I just comment out the "read" on the UART, the NIOS application main loop executes normally (doing pretty much nothing, but toggling LEDs to indicate it is alive).
Does anyone have clues as to what I may have overlooked that could cause this problem ?
Well this is typical. I have been struggling with this for a bit, finally decided to call for ideas here, and then an hour later it hit me: STACK-related issue.
It turns out my NIOS app uses a 4K buffer on the stack, and the build log indicates that around 4500 bytes are free to use for stack+heap. So no wonder I got weird behavior even though I did not even access the mSGDMA, and no wonder small changes unrelated to this made the application work or crash.
I wonder how many times in my developer life I will end-up in stack/heap collision hell, AND not see it immediately :(
Anyway, sorry for the question, I'll proceed with figuring out how/where the NIOSII memory settings are and how to adjust them.