ContributionsMost RecentMost LikesSolutionsRe: NIOSV firmware stuck when juart-terminal is not open for the print messasges. 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. Re: NIOSV firmware stuck when juart-terminal is not open for the print messasges. Could you please verify what is written here? https://www.intel.com/content/www/us/en/docs/programmable/683130/21-4/driver-options-fast-vs-small-implementations-29605.html "fast" version of the driver shouldn't be blocking execution. ~E.V. Re: NIOSV firmware stuck when juart-terminal is not open for the print messasges. 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. Re: Issue after upgrading a Nios V/g core from version 1.0.0 to 4.0.0 Hello Domingo, I have no access to email addresses in the forum. Are you able to share in the forum? Please let me know, if not, we can figure a way out ~E.V. Re: Issue after upgrading a Nios V/g core from version 1.0.0 to 4.0.0 @Benitez__Domingo is there any way you could provide sample code for your issue? We would like to investigate this further internally. Your case might help us to do this. Thanks! ~E.V. Re: Issue after upgrading a Nios V/g core from version 1.0.0 to 4.0.0 Thanks for finding this out Re: Issue after upgrading a Nios V/g core from version 1.0.0 to 4.0.0 Hello, Here some suggestions you can check. - Verify using "System Console" that your NIOSV does not have any reset/clock issue. Navigate to "System Explorer", then unroll the drop-down menu "device"-><device>-> look for warnings or issues in the view. - Try using the juart-terminal with - d <#> -i <#> switches (looking for other <#>) - Using the programmer, you can slowdown the JTAG clocking. In the Quartus Programmer, go to "Hardware Setup.." and reduce the frequency in "Hardware Frequency" - Have you try generating a .hex file for your program and using it in the CPU RAM? - Please verify after doing the "Automatic Upgrade" that nothing was disconnected in your "Platform Designer Project" (this could happen) Just to clarify, are you seeing any printing in the "juart-terminal" at all? Or the CPU starts to execute and then stalls? Thanks, ~E.V Re: Agilex5 JOP Bitstream Configuration Hang Hi @K606 We internally evaluated your issue with the https://www.intel.com/content/www/us/en/support/programmable/articles/000098223.html and concluded they are not related (this is more related with the use of the JTAG chain, that does not prevents the HPS from booting). Your u-boot should be going through... So, please, program your board using the .sof and this would give you and indication of why the "rbf" load is hanging. Sorry for the delay in checking this out. ~E.V. Re: Agilex5 JOP Bitstream Configuration Hang Hi, Yes, it seems like this is the same issue. I'm confirming internally if this was fixed in later Quartus versions. ~EstebanV Re: Agilex5 JOP Bitstream Configuration Hang @K606, Are you programming the JIC file to the QSPI as well? or are you using Quartus programmer to flash the "<name>_hps_auto.sof". In Agilex devices, you need two phases of the bitstream in "HPS First". phase 1 is the (jic of hps_auto.sof), phase 2 is the RBF. You need to update and use both. Please confirm either you are flashing your QSPI with the JIC (this has to be done at least once) or you are using the "<name>_hps_auto.sof" to program your device (using the Quartus programmer) to kick-off the booting process. See this https://altera-fpga.github.io/rel-24.2/embedded-designs/agilex-5/e-series/premium/remote-debug/ug-remote-debug-agx5e-premium/#run-example "Write the QSPI image $TOP_FOLDER/ghrd_a5ed065bb32ae6sr0.hps.jic to flash."