Patrik78
New ContributorJoined 3 years ago
User Profile
New Contributor
User Widgets
Contributions
Re: CFI 32-bit programming
Hi, the configuration you suggest is using a max cpld to program the CFI and this is not what I have in my Hardware. I've only a Cyclone V connected to the external 32 bit CFI Flash and I would like to program it by Nios Flash programmer. Is the 32 bit (16+16) with AMD command set actually supported by Nios Flash Programmer ?CFI 32-bit programming
Hello, I'm trying to program a CFI 32-bit flash, composed by 2 16-bit flash in a parallel configuration, , using quartus_pgm/Nios Flash programmer (Quartus 18.1). Flash memories use AMD command set. I set up a nios2 with a generic tristate controller that seems correctly configured and load at FPGA power on. In fact the raw CFI table read by the programmer seems to be ok. Any ideas of why this error is happening ? Here a screenshot after the command "quartus_pgm --nios2 --base=0x800000 --program" is sent to the shell. Thank you in advance.Re: FIR II Coefficient Reload Problems
Hi, actually the system is composed by Platform Designer, and all the read accesses are made by a Nios II processor. The read access is simply done by a predefined IORD(), as per all the other MM slave in the system that works correctly. So I expect this IORD follow the correct timing diagram. Unlucky reading the one coefficient at first address deadlocks the processor that stop works. Otherwise everything works correctly. Any ideas?FIR II Coefficient Reload Problems
Hello, I am using Quartus version 18.1 and I have a FIR filter in a Nios II QSYS system (created with FIR II). the filter works as expected with the preconfigured coefficients in QSYS. The issue is when trying to reconfigure the FIR coefficients by MM interface, in this case trying to read one coefficient at first address deadlocks the whole system. The interface is configured as read/write. I've found a few similar problems here in the community but without an Intel official reply: https://community.intel.com/t5/FPGA-Intellectual-Property/FIR-Coefficient-Reload-Problmes/m-p/239608 https://community.intel.com/t5/FPGA-Intellectual-Property/Altera-FIR-Compiler-II-15-0-Coefficients-Reload-Issues/m-p/67840 https://community.intel.com/t5/FPGA-Intellectual-Property/FIR-II-Coefficient-Read-from-Cyclone-V-HPS-Freezing/m-p/6808480 Is there a way to get an official Intel answer?Re: UART 16550 IP - Stick parity problem
Hello Sheng, we can't use break signal in our application, so we're forced to make the parity check work without the use of break. Could you check other reasons why the PE is set receiving 0x55 with '0' as parity bit, and not set when receiving 0x57 with '0' as parity bit , assuming receiver is set to check parity MARK?Re: UART 16550 IP - Stick parity problem
Hello Sheng, the hexadecimal 0x55 and 0x57 represent only data bits, not considering start, parity and stop bits. In the example I was describing I receive a 0x55 (or 0x57) data, followed by the parity bit always '0'. As the receiver is configured in MARK stick parity I expected to get a parity error. But as I was saying this happen only if the data is 0x55, in case the data 0x57 I got no parity error.Re: UART 16550 IP - Stick parity problem
Hello Sheng, in our application we don't use break signal, so I expect the BI bit to be always 0 and that's what happen. While it seems parity bit is handled as expected in odd, even mode it seems it does not work in Stick parity mode (mark or space) Here some data: in case I receive in MARK stick parity a 0x55 with '0' as parity bit, I expect to get 0x65 in LSR (assuming we are not transmitting, bit TMTE e THRE are '1'), and that's exactly what I read. But if I receive a 0x57 with '0' as parity bit, I expected to still get 0x65 in LSR... but in this case I read 0x61. So at the end it seems receiving in MARK stick parity mode does not work. Could this be possible ? Any ideas ?Re: UART 16550 IP - Stick parity problem
Hello Sheng, I try to be more clear describing the problem we are facing. Referring to the 16550 IP we are using the Stick Parity function (par 10.2) either in Tx either in Rx. In our design we want to stick the parity to “1” for some Tx data and to “0” for all the other Tx data. On the receiver side we have two Uart in parallel. The first configured with stick parity fixed to “0” and the second with stick parity fixed to “1” In the first Uart the stick the parity set to “0”. We want to store only the received data with stick parity fixed by the Tx Uart to “1” (not related to data bits value) and discard all received data with stick parity fixed by the Tx Uart to “0” (LSR bit 2). In the second Uart the stick the parity set to “1”. We want to store only the received data with stick parity fixed by the Tx Uart to “0” (not related to data bits value) and discard all received data with stick parity fixed by the Tx Uart to “1” (LSR bit 2). In detail when I configure the Stick Parity to "0" on the Receiver Uart, I assume that the parity bit of the received data will generate a parity error in the LSR register (bit 2="1") only if the received data has the parity bit ="1" independently by the value of the data bits ( not calculated but stick to the programmed value in the LCR register) In the following our test bench with two 16550: the first Uart is configured to transmit data with stick parity set to "1" (LCR Bit5 SP="1", Bit4 EPS="0", Bit3 PEN="1") the second Uart is configured to received data with stick parity set to "0" (LCR Bit5 SP="1", Bit4 EPS="1", Bit3 PEN="1"). In our test the second Uart receive the data in polling mode reading and storing the LSR register to check the LSR Bit0 (DR) to find if a new data is available. If a receive data is ready, we check the in the stored LSR register the bit 2 (PE) that should be set to "1" for each received data (reset automatically to "0" after the reading of LSR register). In our test we see that the LSR register bit 2 (PE) sometimes is "0" and sometimes is “1” independently from the stick parity programmed in the receiver Uart. Can you check our test and support us to use the stick parity function in the receiver?
