Chandrashekhar_K
New ContributorJoined 2 years ago
User Profile
New Contributor
User Widgets
Contributions
Re: quartus_hps -c 1 -o I Command error
Dear Jingyang Even for this command quartus_hps -c 1 -o S I'm getting the same errors as in the attachments. For chip erase the same error. Would you please help to understand why the WARM REST is generating a continuous pulse as in previous attachment. The pin is pulled to 3.3V with 4.7K ohm.1.8KViews0likes0Commentsquartus_hps -c 1 -o I Command error
We are trying to programm QSPI on custom board. Running the command before programming QSPI. quartus_hps -c 1 -o I quartus_hps -c 1 -o S We are getting the following errors as in the attached screen shot. Power supply is stable, clock and reset are present for HPS. Part CycloneV 5CSEBA5SU23 Able to programm fpga section via Programmer IDE. Please help to resolve the error.2KViews0likes7CommentsRe: How to implement mutual exclusion for critical sections in code?
Hi @CarlosAM_INTEL , I am using Altera Cyclone V SOC Development kit. I have modified the example code provided alongwith namely, Altera-SoCFPGA-HardwareLib-16550-CV-ARMCC: The interrupt callback function that writes data into the buffer is modified as below: volatile unsigned int tail = 0; volatile unsigned int head = 0; char buffer[ALT_16550_BUFFER_PROVISION_RX_BUFFER_SIZE]; void recieveData(ALT_16550_BUFFER_t * buffer1) { #if ALT_16550_BUFFER_ENABLE_SMP /* Signal we are in the RX section. */ buffer1->isr_rx = true; #endif ALT_STATUS_CODE status = ALT_E_SUCCESS; uint32_t fifo_level_rx; uint32_t copy_size; if (status == ALT_E_SUCCESS) { status = alt_16550_fifo_level_get_rx(buffer1->handle, &fifo_level_rx); } if (status == ALT_E_SUCCESS) { /* Copy the RX FIFO into the RX buffer. */ // alt_16550_int_disable_rx(buffer.handle); // alt_int_global_disable_all(); // portCPU_IRQ_DISABLE(); const unsigned int tail_1 = tail; const unsigned int head_1 = head; // portCPU_IRQ_ENABLE(); if(head_1 < tail_1) { copy_size = stdminul(fifo_level_rx,tail_1 - head_1); }else{ copy_size = stdminul(fifo_level_rx,ALT_16550_BUFFER_PROVISION_RX_BUFFER_SIZE - head_1); } alt_16550_fifo_read(buffer1->handle,&(buffer[head_1]), copy_size); // portCPU_IRQ_DISABLE(); head = (head_1 + copy_size) % ALT_16550_BUFFER_PROVISION_RX_BUFFER_SIZE; // portCPU_IRQ_ENABLE(); // alt_int_global_enable_all(); // alt_16550_int_enable_rx(buffer.handle); /* Disable RX interrupts if the RX buffer is full. */ /* if ((tail == 0) && (head == ALT_16550_BUFFER_PROVISION_RX_BUFFER_SIZE)) { status = alt_16550_int_disable_rx(buffer1->handle); }*/ } } The function in main that reads bytes from the buffer is given below: char readBuffer() { portCPU_IRQ_DISABLE(); const unsigned int tail_1 = tail; const unsigned int head_1 = head; portCPU_IRQ_ENABLE(); if(tail_1 == head_1) { return NULL; } const char data = rxBuffer.buffer[tail_1]; portCPU_IRQ_DISABLE(); tail = (tail_1+1) % ALT_16550_BUFFER_PROVISION_RX_BUFFER_SIZE; portCPU_IRQ_ENABLE(); // alt_int_global_enable_all(); // alt_16550_int_enable_rx(buffer.handle); // alt_int_global_enable(); return data; } #define portCPU_IRQ_DISABLE() \ __asm volatile ( "CPSID i"); \ __asm volatile ( "DSB" ); \ __asm volatile ( "ISB" ); #define portCPU_IRQ_ENABLE() \ __asm volatile ( "CPSIE i"); \ __asm volatile ( "DSB" ); \ __asm volatile ( "ISB" ); I wish to protect access of tail and head. The interrupt function is receiving the whole data. But when we read from the buffer, some bytes are lost ( almost half).1.3KViews0likes2CommentsHow to implement mutual exclusion for critical sections in code?
I have a code, where in the board receives data at a rate of 921600 via uart. This is written into a circular ring buffer in the rx interrupt. The same data is read from the buffer in main in a continuous while loop bytewise. But while reading, the bytes are not as same as the bytes written into the circular buffer. Kindly provide ways to protect the critical sections in the interrupt and main.1.3KViews0likes4CommentsRe: Cyclone V SoC DDR3 Not working
We were able to resolve the issue and the DDR3 is working now. The BELSEL pins are set to boot from QSPI. There was no valid image in QSPI and after connecting the JTAG to debug the preloader, we were able to observer the Chip Select pin kept on asserting. (I understand the JTAG should take priority and CS assertion should stop). We flashed some image and then could observe the CS pin not asserting after connecting JTAG. Still we were not able to make the DDR up in debug mode. Finally disabled the semihosting feature and enabled the serial support in bsp editor and flashed the compiled u-boot spl image to QSPI We were able to see the the ddr3 being calibrated message in teraterm After this we were able to debug the preloader with semihosting enabled. Still not clear with the points 1. The start address the CV Soc kit shows when loading the spl and custom board are different. I think it should be same as the start address after reset will be same for the HPS core. 2. Why there should be some image in boot device to debug the preloder? 3. Why CS keeps asserting even after connecting JTAG without a valid image in it.1KViews0likes0CommentsCyclone V SoC DDR3 Not working
On custom board we are trying to make the DDR3 up. I'm trying to debug the preloader and check the DDR3 working. Have generated handoff files from Quartus prime. Compiled using BSP editor settings and finally generated uboot-spl file. Attached are the DDR3 memory parameters and the error I get while debugging the preloader. DDR3 part no MT41K256M16TW-107IT:P Cyclone V Part no 5CSEBA5U23I7 Quartus 18.1 SoCEDS DS-5 v5.29.1 As the DDR3 is backward compatible to DDR3L-1600, I have used the same SDRAM settings avaialbe in the CV GSRD example. The board setting and the skew values are the defaults I'm not able to make the DDR3 up. The following troubleshooting is done | 1. The regulators outputs for VTT(0.75V), VREF(0.75V) and 1.5V required for DDR3 are at required voltage levels 2. Clock and Reset are OK 3. Schematics are checked and found OK. 4. Able to run hello world example from on chip ram. 5. Very rarely I get the debug message as in the text file attachement Kindly help to reolve the issue to make the DDR3 Up.1.1KViews0likes3Comments