recommended memory map address for changed FPGA code

[HaraldHaug]

Hello,

I just started to try programming a Stemlab125-10.
If I want to change the FPGA code is it then recommended to use
FPGA memory map
CS[6] 0x40600000-0x406FFFFF "FREE"
for data transfer?
Or better extend the "housekeeping"?

I got the impression that following transfer does not work:
uint32_t* aPtr = (uint32_t*)0x40600000;
*aPtr = (uint32_t)0x0ABC;

So the idea would be to
1) change the api (not api2?)
include new files with a new data structure and a BASE_ADDRESS = 0x00600000
use the cmn_Map function to allocate the data to the correct addresses
define some interface functions
2) copy the fpga/prj/v0.94 folder to a new project
in the red_pitaya_top.vs file refer to
sys[6].addr, sys[6].wdata, sys[6].wen
3) create an application software that uses the new interface functions from the api
Is this concept correct???
Are there any existing examples?
Where to place the new api library (*.so?) ?
What *.h files to be updated to make them visible for the application software? In the /opt... folder?

In the FPGA memory map there are specific addresses marked as "read only".
I assume that generally the application can write to all addresses but any change of "read only" data will just be ignored by the FPGA? Or is there any write protect to be considered?

Thanks for the help
regards
Harald

[Nils Roos]

If I want to change the FPGA code is it then recommended to use
FPGA memory map
CS[6] 0x40600000-0x406FFFFF "FREE"
for data transfer?
Or better extend the "housekeeping"?

That depends on your judgement whether your new functions are somehow related to other things in hk or not. If you use some resources that are already handled in hk (unlikely, since hk does not do much nowadays), that would also be an argument. Otherwise, use the free region.

I got the impression that following transfer does not work:
uint32_t* aPtr = (uint32_t*)0x40600000;
*aPtr = (uint32_t)0x0ABC;

User space applications can not use physical addresses without some crutches, because the address space they see is virtualized through the MMU.

So the idea would be to [...] Is this concept correct???

It's a valid concept.

Are there any existing examples?

I'd say the api-sources themselves together with the Examples/C sources should be all the examples you need.

Where to place the new api library (*.so?) ?
What *.h files to be updated to make them visible for the application software? In the /opt... folder?

If you only add functions, just replace the existing lib and header.

In the FPGA memory map there are specific addresses marked as "read only".
I assume that generally the application can write to all addresses but any change of "read only" data will just be ignored by the FPGA? Or is there any write protect to be considered?

There is no write protection to consider. Whether a write succeeds or not depends only on the presence of FPGA logic to handle the writing. If there is no logic in place to process write requests to a specific location, the write will have no effect.

[HaraldHaug]

Hello

thanks for the explanations.
I succeeded extending the "housekeeping" for some user -specific data exchange from software to the fpga
I have put my code plus some explanations on github
https://github.com/haraldhaug/RedPitaya_User_Map0.git

I did NOT succeed using memory map "6" for the same kind of data exchange.
also that attempt is on github
https://github.com/haraldhaug/RedPitaya_User_Map6.git
Can anybody explain what is wrong here

One observation that surprised me:
the /opt/redpitaya/include/redpitaya/rp.h includes additional data structure compared to the RedPitaya/api/include/redpitaya/rp.h
After I copied the api/include/redpitaya/rp.h to the /opt/redpitaya/include/redpitaya/ directory especially the web interface would no longer compile.
Is there some special idea behind that to keep 2 different implementations of rp.h?
My impression was: the main difference is just one typedef struct...
Something like 99% identical files with one minor difference - strange.

regards
Harald

[Nils Roos]

One thing that stuck out is that your RP_FPGA_USR_BASE_ADDR should be 0x40600000 . No other obvious problems.

Regarding the different versions of rp.h: I haven't looked into it in detail, but in the RedPitaya repo ongoing development is done on the master branch. So, master does not reflect the sources of any release.

[HaraldHaug]

Hello,

OK, I have seen that "4" in the memory map document:
but:
in generate.h there is #define GENERATE_BASE_ADDR 0x00200000
housekeeping.h static const int HOUSEKEEPING_BASE_ADDR = 0x00000000;
in oscilloscope.h static const int OSC_BASE_ADDR = 0x00100000;
and mixed signals static const int ANALOG_MIXED_SIGNALS_BASE_ADDR = 0x00400000;
--> I could not find any define with a leading "4"

That is why I have assumed that the "4" should be omitted here.
I actually do not understand that mechanism...
but I can try that

regards
Harald

[HaraldHaug]

I have changed the address to 0x40600000 and now the data exchange works OK!
Do you understand why? I do not. (see above)

[Nils Roos]

See my above comment re: master branch - if you look at the api headers from one of the 0.96 tags, you will find 0x4... for the offsets. The reason is most probably that the mapping mechanism has been changed lately.

You should be careful to base your work on the same sources that went into your ecosystem build. Even if you linked against the librp from your fork, at runtime the symbol resolution will use what's in the system paths - unless you take special precautions like instructing the linker to include a reference to the specific librp used.

[HaraldHaug]

I have tried with the ISO 0.97-RC4 and RC3 combined with the api at the tag v0.97-RC4 and RC3 of github repository
The result is a "segmentation fault" when I write to memory map 6. Same result for memory map 5.
I also have tried with a combination of v0.96 but that also din dot work. The application software din dot compile.

[Nils Roos]

The question is, what version is the installed ecosystem on your Red Pitaya when you run the program? This determines what codebase you need to use.

[HaraldHaug]

I actually did the following steps
go to http://downloads.redpitaya.com/downloads/ and get the red_pitaya_OS-v0.97-RC4_23-feb-2017.img.zip
Install it to a SD card
start the redpitaya, check connection by ssh --> works --> welcome screen indicates 0.97...
git clone https://github.com/RedPitaya/RedPitaya.git
git checkout -b usr97 v0.97-RC4
--> I believe that at this point the ecosystem and the codebase should be consistent
go to RedPitaya/Examples/C and build the digital_led_blink (using the fpga_0.94.bit) --> works OK
rebuild the api trying memory map 6 or 5 -- equivalent to what is on https://github.com/haraldhaug/RedPitaya_User_Map6.git
using address 0x00600000
--> running my rp_usr.c --> causes "segmentation fault"
I have also tried address 0x40600000 - does not change the result
tried "digital_led_blink" again - still OK - i.e. the (updated) API generally works fine