USBSERIAL Reliability Issues with qf_ssi_ai_app

Post Reply
rahmant3
Posts: 4
Joined: Sun Jan 10, 2021 11:17 pm

Hello,

One of the things I'd like to add to my project is the ability to perform diagnostics over the USB serial port, and keep the hard UART reserved for use with a different peripheral. My project is based off of
qorc-sdk/qf_apps/qf_ssi_ai_app/ in qorc-sdk as I felt this would be appropriate starting point to interface with the I2C sensors I needed.

One difference with this project from the helloworldsw project is that it uses a different clock rate 72MHz, but it looks like the code is configured to account for this when configuring the USB SERIAL, so I think it is intended to be a usable feature. It is also mentioned in the SensiML documentation as something that can be enabled in this project (at least for viewing debug output).

I have made the following modifications to enable the USB serial port.

In Fw_global_config.h
1. Set FEATURE_USBSERIAL to 1
2. Set DEBUG_UART to UART_ID_USBSERIAL

Code: Select all

// In Fw_global_config.c
#define FEATURE_USBSERIAL   1       // USBSERIAL port is present
#define DEBUG_UART  UART_ID_USBSERIAL  // Write data to USB serial port
In main.c
1. Set the "int" in the delay loop to "volatile int", as I found it was getting optimized out. Without this, my Windows machine failed to recognize the device.

Code: Select all

// In main.c
    load_fpga(axFPGABitStream_length,axFPGABitStream); // Note that I'm quite confident the correct version of the USB FPGA IP is loaded (i.e. I can see it is the correct revision 0x200 in the debugger).
    // Use 0x6141 as USB serial product ID (USB PID)
    HAL_usbserial_init2(false, true, 0x6141);        // Start USB serial not using interrupts
    for (volatile int i = 0; i != 4000000; i++) ;   // Give it time to enumerate <---- CHANGED
2. Before starting the scheduler, start the CLI task.

Code: Select all

#if (FEATURE_USBSERIAL == 1)
    CLI_start_task( my_main_menu );
#endif
With just these changes, it seems that only part of what is expected will be printed to the terminal. After this, it seems that the USB SERIAL enters into a state where no more data is being printed to the screen.

While playing around with this, one interesting thing I found that is if I commented out this delay in cli_platform.c, that the CLI seems to run OK and I'm able to interact with the board over the USBSERIAL... except after a few minutes it seems to go into a hanging state again and I'm not able to interact with it anymore. Also, this is library code so I would prefer not to have to edit this file at all, but this was discovered while troubleshooting.

Code: Select all

// In cli_platform.c
void CLI_task( void *pParameter )
{
    (void)(pParameter);
    int k;
    
    //wait_ffe_fpga_load();
    /* set to 1 to have a timestamp on the side */
   // vTaskDelay(100);  // <---- CHANGED
Based on the note here, one more idea I had was to also insert a busy wait in the HAL layer, waiting for the USB SERIAL to become empty again. But again, after some time it seems to just enter some kind of hanging state and never empties, and will fail to exit this while loop.

Code: Select all

// In eoss3_hal_fpga_serial.c
void    HAL_usbserial_putc(char c) {
    // Wait for room in Tx FIFO
    while(pusbserial_regs->m2u_fifo_flags == 0)
        ;
    pusbserial_regs->wdata = c;
    // Wait until Tx FIFO is empty
    while(pusbserial_regs->m2u_fifo_flags != 1)
        ;
}
--

Wondering if anybody has any success with using the USB SERIAL with this qf_ssi_ai_app project? As I said this would be a nice feature to use for my project to do some diagnostics and keep the hard UART for one of my peripherals.

Would appreciate ideas or advice on troubleshooting this or thoughts on whether using this feature should be possible like this.
anthony-ql
Posts: 49
Joined: Thu Jun 04, 2020 1:26 am

Has passed your questions to internal team and waiting for their feedback.
murthy.vedula
Posts: 15
Joined: Thu Jun 04, 2020 11:31 pm

The below changes would help with using the USB-serial with simple streaming application project:

1. Enable the macro FEATURE_USBSERIAL, set macro DEBUG_UART to UART_ID_USBSERIAL in Fw_global_config.h
2. Use volatile in the for loop to wait for the USB serial to be recognized by Windows (in main.c)

Code: Select all

for (volatile int i = 0; i != 4000000; i++) ;
In addition to these changes, please add the following changes to the project:

3. Set CONST_FREQ to 1 in Fw_global_config.h

Code: Select all

///* do or do not perform dynamic frequency scaling */
#define CONST_FREQ (1)
//
4. Delay the sensor configuration until a connect string comes from the DCL.
move the following code to ssi_comms.c
Changes to sensor_ssss_config.c

Code: Select all

  /* [TBD]: sensor configuration : should this be here or after scheduler starts? */
  //sensor_ssss_add();
  //sensor_ssss_configure();

Code: Select all

            if (strncmp(ssi_rxbuf, ssi_connect_string, ssi_connect_string_len) == 0)
            {
                is_ssi_connected = true;
                sensor_ssss_add();
                sensor_ssss_configure();
                sensor_ssss_startstop(1);
            }
rahmant3
Posts: 4
Joined: Sun Jan 10, 2021 11:17 pm

Thank you to both of you for the quick response! I saw significant improvements with just this change added.

Code: Select all

///* do or do not perform dynamic frequency scaling */
#define CONST_FREQ (1)
I was able to leave the quickfeather running for over an hour and was still able to interact with it afterwards. Seems much more stable now.

To close the loop on this. Is there an explanation as to why defining CONST_FREQ to 1 appears to fix my issue?
anthony-ql
Posts: 49
Joined: Thu Jun 04, 2020 1:26 am

Thank you for the feedback. CONS_FREQ = 1 forces the EOS S3 to stay at one frequency and not changing frequency. Since the USB port is used for debug and need to stay awake, staying at const frequency helps with the communication.
Post Reply