SuperSpeed Explorer Kit FX3 _ DebugPrint function

[Nzagone]

Hello Infineon,

I am currently learning to work with the EZ-USB FX3 kit and trying to implement some UART messages to follow the execution of my programs with a puTTy terminal.

The CyU3PDebugPrint() function, frome the cyu3system.h library, seems to be made for that purpose, however I have not been able to make it work so far, even though the subject has been discussed many times on this forum.

In particular, I am confused by the fact that there are entire blocks of code dedicated to initializing the UART in the UsbUart example firmware that are not mentioned in this article on how to use the function.

I also tried to import and run the edited Debug firmware provided in this previous discussion about a similar issue, yet cannot read anything in my terminal.

For your information, PuTTy scans the COM port on the USB 2.0 connector, since it is linked with the UART interface, with the default settings (115200 bauds, 8 data bits, no Parity bit, 1 stop bit, no Flow control). Could I be doing this wrong ?

>Do you happen to have a template on how to use this DebugPrint function for a basic application? My next test would be to print a message when the on-board user button is pressed.

>Is there another message-printing function I might have missed and that could be easier to use?

Thanks very much

[AliAsgar · Accepted solution]

Hi,

I assume that the USB serial chip on the superspeed explorer kit is used as a Uart to USB bridge for the UART debug messages. Am I right?
If yes, please share with us the friendly name coming up in the device manager for the USB serial port.

Could you let us know what blocks of code are you specifically talking about in the UsbUart firmware example.
Please note that the UsbUart firmware example is an example to display the CDC functionality of USB by implementing a virtual COM port. This firmware does not make use of the DebugPrint function.

You can connect USB Serial port to the PC and open puTTy. Program FX3 with default USBBulkSrcSink firmware and check if you can see the USB logs.

Could you please share your firmware with us? We will check to see if the problem is reproduced at our end.

Best Regards,
AliAsgar

[Nzagone]

Hi,

Thanks very much for that quick reply.

Following your advice allowed me to finally get some messages in the UART terminal, as expected in the examples.

Here's what I wad oing wrong : at first I tried to use some DebugPrints in the BootLedBlink example, where no UART session is configured ; then I tried to check the output from the GpifToUsb example with PuTTy, where the function is already implemented, but I would only open the terminal after uploading the firmware which means that the startup messages had already been sent.

In the end, starting the terminal session before uploading the firmware was just the tip I needed.

At this point, I don't have any code that would be clean enoug to share, but I have studied the firmware code and I am starting to understand what is required to use the function :

- After importing the relevant libraries such as cyu3uart.h, the CyFxApplndebugInit function is used to setup the debug session and the parameters of the UART terminal. From this point on, the DebugPrint function can be used for UART messages. That is the main 'block of code' I mentioned earlier.

- CyFxAppStart, CyFxAppStop, CyFxAppUSBSetupCB and CyFxAppUSBEventCB define the actions to perform during main USB events (SET-CONF, RESET, DISCONNECT, SUSPEND), including the configuration of the USB, endpoints and DMA channels.

-CyFxAppInit starts the USB session and loads the GPIF configuration if needed.

-AppThread_Entry defines the thread that will be running once the firmware is uploaded and the RTOS kernel is running. It calls the DebugInit and AppInit functions, and if  the users want to get some UART messages providing information on the system status, they will define it there in an infinite loop function.

-AppDefine creates the thread(s) to be used by the RTOS kernel, which calls the AppThread_Entry function as defined just before.

-Finally, the main function configure the IOs and launches the RTOS kernel, starting the thread(s).

I know I've missed some details, but could you please confirm that my understanding of the code structure is correct? It might be quite basic, but could also be useful for other people in this forum.

Thanks again, and have a nice day !

Best regards

[AliAsgar]

Hi,

Yes, on a high level your understanding of the code structure is correct.

Best Regards,
AliAsgar