More information:
The hardware, IP and software I'm using now used to result in a clean, error free stdio type interface over the jtag_usb into the NIOS II Console. I switched stdin, stdout, and stderr to "none" for a time to test the design in a fully embedded environment where there is no console. I made a few changes during that time but nothing major. Now that I have switched stdin, stdout and stderr back to jtag_uart, I am getting strange corruption in data communicated over this interface as indicated in my first post on this problem.
As I mentioned my BSP is set to use the small C library. It is also configured to use the reduced device drivers. These settings are essential; I do not have enough memory available to change these. This has been true from the beginning. Without going into it too much, I am creating an extremely low power system and minimizing board chip count is critical. Using a 16K LE Cyclone III I only have access to 36K of RAM. This has always been true, including the time when i/o with the console worked flawlessly, so I know this is not causing the problem.
I have tried enabling and disabling the lightweight device driver API in the HAL; no effect. I have also tried enabling and disabling the jtag_uart small driver and uart small driver, in the settings available on the "drivers" tab of the BSP editor. No change.
It's always possible there's a hardware issue, but I think it is unlikely; the hardware performs flawlessly otherwise. The behavior reminds me of an old style RS-232 serial connection with mis-matched parameter settings. Doesn't seem like that should happen with USB though.
Has anyone run into this problem and (hopefully) found a solution, or at least a promising lead or avenue for further inquiry? I have googled around and dug through Altera documentation to no avail so far.
Any hints or information on this issue would be greatly appreciated.
LH
Honored Contributor
