New Contributor
Frequent ContributorHello,
The General Settings section is located at the top level of the BSP settings when the BSP Editor is opened. A snapshot is attached for reference. The stdin, stdout, and stderr are currently set to none, but they should be assigned to the JTAG UART instance in your system. Setting these IO streams to "none" would isolate your FW/SW from the console.
From the linker settings, it appears that the system is using on‑chip memory rather than DDR3. In addition, the DDR3 region does not appear in the linker view. If a DDR controller is included in your Qsys design, this may indicate that it is not connected to the Avalon‑MM bus.
Given the current on‑chip RAM configuration, it is recommended to create a simple Hello World application and run it to verify basic system functionality and help isolate any unexpected design issues.
Thank you,
Fawaz
New ContributorHi Fawaz,
These points were set just after it was originally suggested but did not help. So it is not likely the issue is with the log console.
You are right about the linker so the DDR3 areas are not listed. Perhaps because they are not connected to NIOS data bus directly but via address extenders. Now they are added to the list by hand (nios_ddr3 and trace_ddr3):
SW code downloads well to 0x40000000 which is nios_ddr3 memory region so the DDR3 address range and the RAM itself should work well.
We tested this bsp as well but the situation still did not change.
Do you have any other suggestion what to check?
BR,
Istvan
New ContributorAny idea?
I am thinking on adding a Signaltap to discover what is happening. But which signals should be probed in this case? To get some usable information about the situation? Is there some useful internal signals to check, or just external Avalon MM?
Frequent ContributorHello Steve,
Have you tried debugging the application using the Nios II Eclipse Debugger? Setting breakpoints after the function can help determine where the application is getting stuck. You can also use SignalTap to observe internal signals, and the Nios II plug‑in to capture the processor’s address and data activity. The external Avalon‑MM signals should be sufficient for this level of debugging. However, before relying on hardware traces, I recommend stepping through the application in the Nios II debugger to identify which specific function call is causing the issue.
Thank you,
Fawaz.
ModeratorHi steve_ht,
Good day, just following up on the previous clarification.
By any chances did you managed to look into it?
Hope to hear from you soon.
Best Wishes
BB
