Forum Discussion

prashant_gohel's avatar
prashant_gohel
Icon for New Contributor rankNew Contributor
5 months ago

NIOSV firmware stuck when juart-terminal is not open for the print messasges.

Hi,

I am facing an issue where the NIOSV firmware gets stuck if the JUART terminal is not open for printing messages. Once I open the JUART terminal, everything works fine.

Is there any way or BSP setting I can use to prevent the NIOSV firmware from getting stuck when the JUART terminal is not open?

9 Replies

  • EstebanV_Altera's avatar
    EstebanV_Altera
    Icon for Occasional Contributor rankOccasional Contributor

    Hello,

    This is not usual behavior, the default shouldn't behave like this. Are you having prints into the terminal? If you remove such prints the programs continues?

    Which Quartus version are you using? Which NIOSV version (G,C,M)?

    Please provide as much details as possible so I can reproduce

    ~E.V.

    • prashant_gohel's avatar
      prashant_gohel
      Icon for New Contributor rankNew Contributor

      Hi Esteban,

      I am using Quartus 25.1 with NIOSV version M.

      When the terminal is open, everything works fine, but if I close the terminal, the NIOSV gets stuck. Our requirement is that the NIOSV should run normally without needing the terminal to be open.

  • dim1's avatar
    dim1
    Icon for New Contributor rankNew Contributor

    When you generate BSP, go to the JUART Driver settings - there is an option to allow the driver to ignore when the output FIFO is full. Enable that option and it will not wait for somebody to read the output.

  • EstebanV_Altera's avatar
    EstebanV_Altera
    Icon for Occasional Contributor rankOccasional Contributor

    Please confirm both setings pointed out by me and @dim1

    In the BSP should appear as: altera_avalon_jtag_uart_driver.enable_small_driver = false and/or altera_avalon_jtag_uart_driver.enable_jtag_uart_ignore_fifo_full_error = true

    ~E.V.

  • LiangYuG_Altera's avatar
    LiangYuG_Altera
    Icon for Occasional Contributor rankOccasional Contributor

    Hi prashant_gohel​,

    Can you try to modify the alt_sys_init.c?
    Our team found that the current auto-generated initialization sequence is causing the JTAG UART fast driver to malfunction.

    Current (Failing) - Nios V processor is initialized last.

    void alt_sys_init( void ) 
    { 
        ALTERA_AVALON_JTAG_UART_INIT (JTAG_UART, jtag_uart); 
        INTEL_NIOSV_M_INIT (NIOS, nios); 
    } 


    Modified (Passing) - Nios V processor is initialized first.

      void alt_sys_init( void ) 
    { 
        INTEL_NIOSV_M_INIT (NIOS, nios); 
       ALTERA_AVALON_JTAG_UART_INIT (JTAG_UART, jtag_uart);  
    } 

    We believe that the JTAG UART initialization have some dependency on Nios V processor initialization.
    As such, Nios V processor should be the first to initialize.

    Regards,
    Liang Yu

  • tehjingy_Altera's avatar
    tehjingy_Altera
    Icon for Regular Contributor rankRegular Contributor

     

    Dear Customer, 

     

    Since no further clarification is needed on this thread, it will be transitioned to community support for further help on doubts in this thread. 

    Please login to the Altera Community Forum 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. 

    Thank you for the questions and as always pleasure having you here. 

     

    Best Wishes 

    tehjingy