BeB
Occasional ContributorUser Profile
Occasional Contributor
User Widgets
Contributions
Re: Why overwrite/reset the complete edge register in a PIO ISR?
Hello, Sorry for the late reply. Your suggestion concerns the pio output register, which was not really the matter. I am trying to understand why the complete variable 'edge_capture_ptr' should be overwritten when reading the edge capture register, and whether information from previous interrupts may be lost because of that. Thank you! Bertrand674Views0likes0CommentsRe: segmentation fault with nios2-terminal and printf/alt_printf statements
Hello, Sorry for the late reply. It seems that changing the size of the stdout uart buffer solved the problem. A too large buffer causes the segmentation fault. Reducing the buffer size eliminated the issue (with the exact same code otherwise!). Thank you, Bertrand924Views0likes0CommentsRe: segmentation fault with nios2-terminal and printf/alt_printf statements
Hello, Sorry for the late reply. A simple 'hello world' works fine. It seems that changing the size of the stdout uart buffer solved the problem. A too large buffer causes the segmentation fault. Reducing the buffer size eliminated the issue (with the exact same code otherwise!). Thank you, Bertrand923Views0likes0CommentsWhy overwrite/reset the complete edge register in a PIO ISR?
Hello, Refering to the Nios 2 software handbook (code below), why overwrite *edge_capture_ptr completely and clear the entire edge capture register with IOWR_ALTERA_AVALON_PIO_EDGE_CAP systematically? Let's say that there are 2 buttons for this PIO. If two buttons are activated very close to each other, wouldn't the second ISR call overwrite *edge_capture_ptr? So if the program was slightly busy doing something else in the mean time, it would miss the first button. Why not do a logical OR with the current value obtained with IORD_ALTERA_AVALON_PIO_EDGE_CAP and let the program clear the corresponding bit of *edge_capture_ptr when it has done what it is supposed to do. With the IOWR operation: why not just reset the one edge that was detected instead of doing a blanket reset? Thanks! Bertrand #include "system.h" #include "altera_avalon_pio_regs.h" #include "alt_types.h" #ifdef ALT_ENHANCED_INTERRUPT_API_PRESENT static void handle_button_interrupts(void* context) #else static void handle_button_interrupts(void* context, alt_u32 id) #endif { /* Cast context to edge_capture's type. It is important that this be declared volatile to avoid unwanted compiler optimization. */ volatile int* edge_capture_ptr = (volatile int*) context; /* * Read the edge capture register on the button PIO. * Store value. */ *edge_capture_ptr = IORD_ALTERA_AVALON_PIO_EDGE_CAP(BUTTON_PIO_BASE); /* Write to the edge capture register to reset it. */ IOWR_ALTERA_AVALON_PIO_EDGE_CAP(BUTTON_PIO_BASE, 0); /* Read the PIO to delay ISR exit. This is done to prevent a spurious interrupt in systems with high processor -> pio latency and fast interrupts. */ IORD_ALTERA_AVALON_PIO_EDGE_CAP(BUTTON_PIO_BASE); }943Views0likes7Commentssegmentation fault with nios2-terminal and printf/alt_printf statements
Hello, I am running into segmentation faults using either alt_printf or printf to output debug messages from a nios 2 application via the nios2-terminal application. The code runs fine without the debug print messages, and also runs fine with the debug print messages in debug mode with breakpoints at the troublesome debug print statements. I will add that some debug print messages are printed normally, so it is not a systematic issue with printf / alt_printf. Changing the messages that fail still leads to a segmentation fault (reducing the size of the message or the nature of it - integer vs string for example). It cannot be a code issue since it's running fine in debug mode. I am a bit lost here. My RAM should be more than large enough: $ nios2-elf-size nios_app.elf text data bss dec hex filename 34892 884 376 36152 8d38 nios_app.elf $ nios2-stackreport nios_app.elf Info: (nios_app.elf) 35 KBytes program size (code + initialized data). Info: 91 KBytes free for stack + heap. I have the feeling that the issue comes from the JTAG uart. I have seen suggestions online to flush the stdout with fflush, but Eclipse fails to resolve the reference to fflush although stdio.h is included. Could be because I am running the economical Nios implementation? Increasing the JTAG uart buffer size or decreasing it does not seem to make a difference. Thank you for any suggestions! Bertrand1.3KViews0likes10CommentsAdd .QKY file option is greyed out in Quartus Programmer v19.1
Hello, I am trying to program a public root key for authentication with Quartus 19.1 on a Stratix 10 FPGA (1SX280LN3). We are using version 19.1 for license reasons and upgrading is not really an option at the moment. I am following the steps in the attachment (security guide v19.1, section 3.5). In the Programmer, the action "right click the image of the Stratix 10 device and select Edit > Add QKY file" is not even available (greyed out). There doesn't seem to be an obvious reason why this is the case in the rest of the document. Any insight would be greatly appreciated! Thank you, Bertrand Bastien1.7KViews0likes4CommentsRe: Programming of non-volatile root key (.qky) on Stratix 10 1SX280LN3 fails (code 0x3FF)
Hello, No I have never programmed a non-volatile key. It's the first time that I am trying. My current firmware is not signed and works normally, therefore there is no key programmed on the device. Thank you! Bertrand607Views0likes0CommentsProgramming of non-volatile root key (.qky) on Stratix 10 1SX280LN3 fails (code 0x3FF)
Hello, I am trying to enable authentication on a Stratix 10 SoC (1SX280LN3), and religiously following the security guide from Intel. The first steps involve the generation of private and public .pem files, and the generation of a root key file (.qky). The .qky file must then be programmed on the device and this is when things go sideways. Programming the .qky in a volatile fashion works without an issue, but when programming it in a non-volatile fashion, I get an error from Quartus Programmer: code 0x3FF. I cannot find any reference anywhere about what that means. I have attached the screenshot in attachment. Is there any setting to enable the non-volatile programming of the .qky, other than enabling the option in Quartus Programmer? Many thanks for any insight! Bertrand735Views0likes3Comments