Nios V juart-terminal Continuously Returns EOF with getchar();

[kyeh]

Hello all,

I am fairly new to working with FPGAs so please be gentle.

We are utilizing the Cyclone 10 GX Development Kit and programmed the Nios V IP to act as our microprocessor. The µC/OS-II is being used as the real-time operating system. We are currently developing with Quartus 23.3.

The prototype "interface" we are currently using is just a while loop with a getchar(); function and a couple switch statements for different functions based on which button you press. The getchar() function continuously returns an EOF signal which I see in the RiscFree debugger as -1. On juart-terminal, this symbol shows as an unknown ASCII character with a int value of 255. We have also used alt_getchar() as recommended by the Nios V Processor Development Handbook but the issue persists.

Previously, this signal would occasionally show up during start up but currently it appears to be a constant input in juart-terminal. I have implemented conditional statements to ignore ASCII inputs outside the range of normal keyboard operations but it seems like a temporary fix. Any recommended strategies to assist with debugging?

[aikeu]

Hi kyeh,

Can you provide some log as reference regarding the output from the console?

Thanks.

Regards,

Aik Eu

[aikeu]

Hi kyeh,

May I know any follow up from the previous comment?

Thanks.

Regards,

Aik Eu

[kyeh]

Hello aikeu,

Apologies for the delay. The program is based off the simple_socket_server example. In juart-terminal, the EOF char returns as an unrecognized char. When I use the %d declaration in alt_printf(), it returns the value 255.

In the RiscFree IDE Debugger, this input can be seen as -1 under the variables tab.

[aikeu]

Hi kyeh,

I am suspecting the UART signal line is not stable where it goes low to trigger a start signal then interpreting the next high signal as data which is high(0xFF or 255). Will need to check if your system is in a stable operation state only start the getchar() while loop. ( Check for the example UART signal characteristics)

You can try to probe the UART signal during the boot up state of your system and also during a stable operating state of your system to see if there is any false signal triggering in the process.

In your application, there must be some control to when is considered to be ok to perform getchar() which is when the system is stable. Example like make sure the system is already boot up with some delays then only perform the while loop to gethar().

If your system is stable and the issue still persist then there must be other contributing factors which requires further troubleshooting.

The UART signal probing is important for troubleshooting in order to check the analog signal stability.

Thanks.

Regards,

Aik Eu

[aikeu]

Hi kyeh,

Any further up from the previous comment?

Thanks.

Regards,

Aik Eu

[kyeh]

Hello aikeu,

Thanks for checking back. I am currently investigating possible instability within the UART read_data lines. My concern currently seems to be the Avalon av_readdata bus. It fluctuates between "@5" (0x0040_3501) and "@" (0x0040_A401) in the background. Here I set signaltap to trigger when I enter "A". I do confirm on the RiscFree debugger that the device still returns EOF. I am currently unsure how this would return EOF but will look further into it.

Thanks,

kyeh

[aikeu]

Hi kyeh,

If there any further question? If no I will transition this thread to community support.

Thanks.

Regards,

Aik Eu

[aikeu]

Hi kyeh,

I now transition this thread to community support. If you have a new question, Please login to ‘https://supporttickets.intel.com/s/?language=en_US’, view details of the desire request, and post a feed/response within the next 15 days to allow me to continue to support you. After 15 days, this thread will be transitioned to community support. The community users will be able to help you on your follow-up questions.

Thanks.

Regards,

Aik Eu