User Profile

Archer_Altera

Occasional Contributor

23 Posts5 LikesLikes received1 Solution

View All Badges

User Widgets

Contributions

Re: Reading S25FL256S OTP region via QSPI Indirect Transfer on Cyclone V HPS — data comes back incorrect
Hi miscellaneous-mice, Thanks for your update. Looks like you have found the root cause and tested with the code you shared, is this solution good enough for your project to move on? Archer_Altera
1 month ago Place SoC System
26Views
0likes
1Comment
Re: Reading S25FL256S OTP region via QSPI Indirect Transfer on Cyclone V HPS — data comes back incorrect
Hi miscellaneous-mice, Please try following 4 items on your side and see anyone can solve the issue. Item 1: Manually Increase Dummy Cycle Configuration Although the datasheet specifies 8 dummy clocks, the Cyclone V QSPI controller in indirect mode sometimes requires an additional cycle to compensate for internal delays. Try setting dummy cycles to 16 (equivalent to 2 bytes) to check alignment: read_cfg.dummy_cycles = 16; // Attempt to increase dummy cycles Forces the controller to wait longer before data arrival, ensuring the internal FIFO pointer points to the first valid data. Item 2: Verify and Force Address Length Configuration You set .addr_size = 2 (representing 3 bytes). Ensure the register is actually written after calling alt_qspi_device_size_config_set. More importantly, explicitly reset certain controller states before switching back to Quad mode or before each Indirect read. Attempt to execute a small STIG read (e.g., reading the status register) before performing an indirect read to “wake up” or synchronize the controller to Single SPI mode: // Perform a small STIG operation to synchronize status before indirect read uint8_t dummy_sr; alt_qspi_stig_rd_cmd(0x05, 0, 1, &dummy_sr, timeout); // Read Status Register // Then perform indirect read alt_qspi_read(dst, src, size); Item 3: Correcting Post-Read Offset (Software Workaround) If you confirm the hardware behavior is reading an extra 0xFF (this has appeared in errata for some Flash controllers, where Indirect Read always includes a leading dummy byte), you can handle it at the software level: Allocate 1 extra byte when allocating the buffer. After reading, shift the pointer back by 1 byte, or skip the first byte during copying. // Temporary buffer, allocate 1 extra byte uint8_t temp_buf[size + 1]; // Execute read operation alt_qspi_read(temp_buf, src, size + 1); // Note: Length must match here, or read only size while ignoring the first byte // Data actually starts at temp_buf[1] memcpy(dst, temp_buf + 1, size); Verification method: If you observe temp_buf[0] always being 0xFF while temp_buf[1] contains correct data like 97, this confirms a fixed 1-byte leading offset in the controller. Item 4: Check alignment of INDRDCNT and INDRDSTADDR Cyclone V QSPI data register accesses sometimes require 4-byte alignment. If your dst pointer is not 4-byte aligned, or size is not a multiple of 4, the memcpy inside the HAL library may fail, or misalignment may occur when the hardware FIFO pops. Ensure the dst pointer is 4-byte aligned (((uint32_t)dst % 4) == 0). If size is small, try rounding up to a multiple of 4 for reads, then truncating to valid data. Archer_Altera
1 month ago Place SoC System
2Views
0likes
3Comments
Re: SDRAM calibration failed.
Hi qwitza Thanks for uploading the error log. The function test_load_patterns(0, ALL) returned 170, but the expected value was 255. This indicates that the test pattern written to DDR (typically 0xFF) was read back as 0xAA (i.e., 170). Since 0xAA is 0b10101010 and 0xFF is 0b11111111, this suggests that certain DQ bits are stuck at 0. Since only two boards have this issue, it is most likely hardware issue such as DQ pin connectivity issues (open circuit, short circuit, or poor soldering). Hope this is helpful. Archer_Altera
5 months ago Place SoC System
76Views
0likes
0Comments
Re: SDRAM calibration failed.
Hello qwitza, Can you let me know which uboot version you prefer to use? I will try to find the solution on it. Regards, Archer_Altera
5 months ago Place SoC System
136Views
0likes
0Comments
Re: ERROR building simple NIOSV Compact project
Hi Barry, You may use link below as an entry to find more Nios V related document. https://www.altera.com/design/guidance/nios-v-developer Hope this is helpful. Archer_Altera
5 months ago Place Nios® System
16Views
1like
0Comments
Re: SDRAM calibration failed.
Hi @qwita, Is it convenient for your design to upgrade uboot version to 2024.07 or later? This will be helpful for me to investigate this case and support you. It will be benefit for you to get support in later development process. If it is not convenient, I will try to help you with uboot 2020.01 version. For both ways, please give me some time to run on hardware to find the correct method. By the way, latest uboot, linux guidance document for cyclone V device is posted on link below. https://altera-fpga.github.io/rel-25.1.1/embedded-designs/cyclone-v/sx/soc/boot-examples/ug-linux-boot-cve-soc/ Regards, Archer_Altera
5 months ago Place SoC System
135Views
0likes
0Comments
Re: ERROR building simple NIOSV Compact project
Hi Barry, Only qip file is needed. Regards, Archer_Altera
5 months ago Place Nios® System
32Views
1like
5Comments
Re: ERROR building simple NIOSV Compact project
Hi Barry, Rather than Adding QSYS into project, please add QIP into the project. From 25.1std, the tool supports QIP only due to a change in Quartus compiler. The tool also prompts with message below. You may find a qip file located in the same folder of qsys system top level hdl file under project directory liking this. Hope this is helpful. Archer_Altera
5 months ago Place Nios® System
85Views
1like
7Comments
Re: ERROR building simple NIOSV Compact project
Hi Barry, I can reproduce the issue you met on my side. This needs time for us to find the root cause. I will let you know when there is progress about this. Regards, Archer_Altera
5 months ago Place Nios® System
78Views
1like
9Comments
Re: Intermittent alt_exception_unknown
Hi @BBS3000, Thanks for letting me know that you will try a newer version. It may be helpful in your usage scenario. I see below case having some discussion about fifoed avalon uart. It has useful info, please refer to it. Why "fifoed avalon uart" was removed from web site ? - Intel Community For the driver part, it is not designed to consider all potential conditions and handle them properly as avalon uart IP. The designers have to evaluate the capability of the IP core they are using and find alternate solution if performance can't be satisfied. Such as using one more Nios core to offload part of processing task. Regards, Archer
7 months ago Place Nios® System
215Views
0likes
0Comments