Redpitaya Forum

and then change line 49 in adc-recorder.c to *(uint32_t *)(cfg + 50) = size;

That is it. The address of 32-bit accesses must be aligned to 32 bits. 50 bytes is not a multiple of 32 bits.

Here is a link to ARM documentation on alignment behavior:

https://developer.arm.com/documentation ... or?lang=en

Thank you for you help Pavel.

By the way, where or how do the base addresses x4*** and x41*** for cfg and sts get assigned in the Vivado?

The address ranges of the M_AXI_GP0 and M_AXI_GP1 interfaces are shown in table 4-1 of the Zynq-7000 TRM. 0x40000000 is the base address of the M_AXI_GP0 interface. The AXI4 hub uses bits 24 to 27 of the address to select one of its ports. The complete table of addresses can be found at this link.

Hi Pavel,

P.S. Never mind the following - I had a legacy RAM shrink settings sneak into my build. I switched to your pre-compiled image It went through allocating OK so far, although it hangs up afterwards. I'll look into that next.


I tried increasing CMA memory to 256MB as follows in the adc_recorder example:
- edited the last line uEnv.txt on sdcard root to '... cma = 290M' (also tried 272M)
- changed const_1 in block design to 2097151
- changed ADDR_WIDTH in axis_ram_writer to 21
- changed requested size in ioctl(fd, CMA_ALLOC, &size) to 256 MB

ioctl returns an error ' Cannot allocate memory'

I also noticed that 'free' shows total 117612 memory, perhaps it is shrunk?

I wonder if I'm missing something again.

Hi Pavel,

Apologies for keeping bothering you - I got adc_recorder example with the expanded memory working OK on Red Pitaya 125 with all your help.

For some reason adc_recorder does not seem to work on the Red Pitaya 122.88 board - it hangs the system around line 49 in the adc-recorder.c, even with the unmodified example. I tried both 122.88 and 125 PLL clock settings, both work on RP 125 and hang on RP 122.88

I tried 2 different 122.88 boards with the same result.

I am glad that memory allocation now works for you. I did not know why it did not work before.

Regarding the new issue, are you building the bitstream files for the 122.88 boards with the correct part number (PART=xc7z020clg400-1)?

pavel wrote: ↑

Wed Jan 10, 2024 10:42 am

I did not know why it did not work before.

The allocations of big buffer was failing because I built the OS with only 128M of RAM. I fixed that.

pavel wrote: ↑

Wed Jan 10, 2024 10:42 am

Regarding the new issue, are you building the bitstream files for the 122.88 boards with the correct part number (PART=xc7z020clg400-1)?

Thanks! That stopped the example from hanging the system

pavel wrote: ↑

Wed Jan 10, 2024 10:42 am

Regarding the new issue, are you building the bitstream files for the 122.88 boards with the correct part number (PART=xc7z020clg400-1)?

Is it possible to determine Xlinx part and/or Red Pitaya model programmatically? We have a number of different Red Pitaya models deployed over the years and I wonder if we can avoid mismatching the builds.

Also, are there markings on the boards to help distinguish particular product lines? E.g. basic 125-14 vs low-noise 125-14? I cannot find any myself.

I normally use the following command to programmatically check the hardware revision:

I wrote the difference between standard STEMlab 125-14 and STEMlab 125-14 Low Noise in this thread.

The visual difference applies to all boards, while the difference from the program point of view applies to the official Red Pitaya OS.

Otherwise, the board model is stored in the EEPROM (in the hardware revision number), which you can read with the: as Pavel mentioned.