Help with odd problem

Applications, development tools, FPGA, C, WEB
erikgroving
Posts: 13
Joined: Tue May 26, 2015 9:10 pm

Help with odd problem

Post by erikgroving » Tue May 26, 2015 9:50 pm

Hello everyone,
I am running into an error with a small modification I've made to the FPGA design. For debugging without an oscilloscope, I have rerouted the DAC output to the scope file and added the data to the bus, whilst creating a buffer of 16kb size just like the ADC. Regarding control signals, I am using the same as the ADC since there is a lot of overlap. Write pointer is also the same since updates will occur at the same time.

Anyway, this is the part of the code that breaks everything (actually everything, all web app will display is 404 not found, ssh and serial are also a no-go's)
At the bottom of red_pitaya_scope.v:

Code: Select all

....
     20'h00048 : begin ack <= 1'b1;          rdata <= {{32-25{1'b0}}, set_b_filt_kk}      ; end
     20'h0004C : begin ack <= 1'b1;          rdata <= {{32-25{1'b0}}, set_b_filt_pp}      ; end

     20'h1???? : begin ack <= adc_rd_dv;     rdata <= {16'h0, 2'h0,adc_a_rd}              ; end
     20'h2???? : begin ack <= adc_rd_dv;     rdata <= {16'h0, 2'h0,adc_b_rd}              ; end
	  20'h3???? : begin ack <= adc_rd_dv;	 	rdata <= {16'h0, 2'h0,dac_a_rd}					; end
	  20'h4???? : begin ack <= adc_rd_dv;	 	rdata <= {16'h0, 2'h0,dac_b_rd}					; end
       default : begin ack <= 1'b1;          rdata <=  32'h0                              ; end
If I comment out the lines beginning with the dac bus data: 20'h3????: , 20'h4????: , it works just fine. One thing to add is when commented out, there is no timing issue, when uncommented, there is a timing issue of 0.036 nanoseconds. However, I do not believe it is a timing issue because removing the adc data on the bus and replacing it with dac data (in the 20'h1???? and 20'h2???? addresses) also results in the same failure mentioned above, and it also does not have a timing error. The web app has already been successfully modified to displays 2 graphs but now I just need to get the data there. It is also not a memory-space limitation, as the placement results indicate I am using 70% of the BRAM, and have not gone over. Any idea what on earth this could be?

erikgroving
Posts: 13
Joined: Tue May 26, 2015 9:10 pm

Re: Help with odd problem

Post by erikgroving » Tue May 26, 2015 10:53 pm

OK I am silly. I had improperly shut down the Pitaya before while the mounted microSD card was still rw-mode because I have been scp'ing my controller.so files to the card... Anyway, after repairing the card I'm all fine, apparently when the mounted file system is improper, there are issues writing the bitstream to the fpga, ok, we're fine. False alarm.

Slight note to everyone: if you make the mounted file system read write, remember to make it read only when you power down the pitaya, otherwise... well, problems arise ;) .

Nils Roos
Posts: 1441
Joined: Sat Jun 07, 2014 12:49 pm
Location: Königswinter

Re: Help with odd problem

Post by Nils Roos » Tue May 26, 2015 11:55 pm

Glad you found it out yourself. Maybe it's also worth noting that the latest ecosystem - the one with librp etc. included - mounts the sd card writable from the get-go.

erikgroving
Posts: 13
Joined: Tue May 26, 2015 9:10 pm

Re: Help with odd problem

Post by erikgroving » Fri May 29, 2015 8:59 pm

I have one other question related to my attempt to get 4 channels on the scope.

Under the scope+pid application there is a function called rp_get_signals:

Code: Select all

 971 int rp_get_signals(float ***s, int *sig_num, int *sig_len)
 972 {
 973     int ret_val;
 974     int sig_idx;
 975 
 976     if(*s == NULL)
 977         return -1;
 978     
 979     *sig_num = SIGNALS_NUM;
 980     *sig_len = SIGNAL_LENGTH;
 981     fprintf(stderr, "Using this for signals: %08x\n", (int)*s);
 982     ret_val = rp_osc_get_signals(s, &sig_idx);
 983 
 984     /* Not finished signal */
 985     if((ret_val != -1) && sig_idx != SIGNAL_LENGTH-1) {
 986         fprintf(stderr, "not finished yet\n");
 987         return -2;
 988     }
 989     /* Old signal */
 990     if(ret_val < 0) {
 991         return -1;
 992     }
 993     
 994     return 0;
 995 }  
What I'm confused about is how it is never instantiated, so I would like to ask where are the inputs coming from? I am currently seg faulting when I access beyond s[2], (i.e, s[3]) , when this function calls rp_osc_get_signals. I would like to change the memory allocation for this but I do not know where, since the function seems to never be called.

This is my modified rp_osc_get_signals function. The memory allocated to rp_osc_signals is fine and I can access the data there, but I have no clue where I can change the amount of memory that is being allocated to ***signals.

Code: Select all

 179 int rp_osc_get_signals(float ***signals, int *sig_idx)
 180 {
 181     float **s = *signals;
 182     pthread_mutex_lock(&rp_osc_sig_mutex);
 183     if(rp_osc_signals_dirty == 0) {
 184         fprintf(stderr, "rp_osc_signals was not dirty\n");
 185         *sig_idx = rp_osc_sig_last_idx;
 186         pthread_mutex_unlock(&rp_osc_sig_mutex);
 187         return -1;
 188     }
 189     
 190     memcpy(&s[0][0], &rp_osc_signals[0][0], sizeof(float)*SIGNAL_LENGTH);
 191     memcpy(&s[1][0], &rp_osc_signals[1][0], sizeof(float)*SIGNAL_LENGTH);
 192     memcpy(&s[2][0], &rp_osc_signals[2][0], sizeof(float)*SIGNAL_LENGTH);
 193     fprintf(stderr, "\nmemory address for s: %08x, memory address for rp_osc_signals: %08x\n", (int)*signals, (int)rp_osc_signals);
 194     memcpy(&s[3][0], &rp_osc_signals[3][0], sizeof(float)*SIGNAL_LENGTH);
 195     fprintf(stderr, "\nSeg faulting prev line\n");
 196     memcpy(&s[4][0], &rp_osc_signals[4][0], sizeof(float)*SIGNAL_LENGTH);
 197     *sig_idx = rp_osc_sig_last_idx;
 198     
 199     rp_osc_signals_dirty = 0;
 200     pthread_mutex_unlock(&rp_osc_sig_mutex);
 201     return 0;
 202 }
Thanks

erikgroving
Posts: 13
Joined: Tue May 26, 2015 9:10 pm

Re: Help with odd problem

Post by erikgroving » Fri May 29, 2015 9:05 pm

A little extra material.

Image.

So when the rp_osc_signals memory is allocated. The address corresponds to the memcpy function address, as expected. But I can't find the source of that ***signals address.

Nils Roos
Posts: 1441
Joined: Sat Jun 07, 2014 12:49 pm
Location: Königswinter

Re: Help with odd problem

Post by Nils Roos » Sat May 30, 2015 12:43 am

Hi Erik,

The function rp_get_signals() is called from rp_data_get_signals() in the bazaar module of nginx (see rp_data_cmd.c, line 413+). The memory allocation also happens there, and after the call the read values are transformed into the json reply to the web-app's client.

If you are wondering why you couldn't find the call, it's because the function's address is looked up by name with dlsym() at runtime when the app is loaded (see rp_bazaar_app.c, line 338+).

I hope this helps
Nils

erikgroving
Posts: 13
Joined: Tue May 26, 2015 9:10 pm

Re: Help with odd problem

Post by erikgroving » Mon Jun 01, 2015 3:36 pm

Yep, that helps a ton, thanks Nils.

erikgroving
Posts: 13
Joined: Tue May 26, 2015 9:10 pm

Re: Help with odd problem

Post by erikgroving » Mon Jun 01, 2015 3:43 pm

Sure enough, it's hard coded with a number (3) and not a define in that source file!! OK, that fixes everything.

erikgroving
Posts: 13
Joined: Tue May 26, 2015 9:10 pm

Re: Help with odd problem

Post by erikgroving » Mon Jun 01, 2015 9:50 pm

Is there any way I can change this value on the server without having to rebuild the entire nginx server?

I'm having troubles rebuilding it. I've spent a good amount of time diving into where and what everything is, installing pcre and zlib, but it still won't build. Any advice on how to build the nginx or is there an easier way to implement this change? I didn't see anything about it in the developer's guide either.

Nils Roos
Posts: 1441
Joined: Sat Jun 07, 2014 12:49 pm
Location: Königswinter

Re: Help with odd problem

Post by Nils Roos » Tue Jun 02, 2015 9:26 pm

I have not tried to build nginx seperately - only as part of a full ecosystem build.

Looking through the Makefiles led me to believe it should be possible to "make build/sbin/nginx" from the Red Pitaya main Makefile. It depends on the RAMdisk, so it will take a while on the first run (I am executing the build in the background right now).

So far, the build seems to be progressing normally. I did:

Code: Select all

cd RedPitaya
source /opt/Xilinx/Vivado/2013.3/settings64.sh
export CROSS_COMPILE=arm-xilinx-eabi-
make build/sbin/nginx

Post Reply
jadalnie klasyczne ekskluzywne meble wypoczynkowe do salonu ekskluzywne meble tapicerowane ekskluzywne meble do sypialni ekskluzywne meble włoskie

Who is online

Users browsing this forum: No registered users and 26 guests