RTC_DATA_ATTR shows strange offset

[psych_uk]

First post here.

I have written an ULP program (which works 100%) using the macro assembler. I want to be able to access shared data between the ULP program and the main program. My understanding that this is done using the RTC_DATA_ATTR.

If I declare a structure using this method (shown below):

Code: Select all

struct ulpvars_t {
	int32_t counter;
};
RTC_DATA_ATTR ulpvars_t ulpvars;

The address of the structure (`ulpvars`) shows at address 0x50000200, instead of 0x50000000 as I would expect.
This means, if I have a ULP program which exceeds 512 bytes (128 instructions), it would collide with this data area?
This is confirmed.

Code: Select all

ulpvars.counter = 0xFFFF;

Places 0xFFFF at instruction 127 in RTC memory.
Do I have to force my assembly past this point to accommodate this offset?
ULP memory isn't so big that losing 128 instructions is acceptable to me.
I have checked all the libraries for other variable marked with this attribute and I cannot find any, my original thought was another library was storing data using this attribute and therefore pushing my declaration higher in memory.

[boarchuz]

Arduino is pre-compiled with CONFIG_ULP_COPROC_RESERVE_MEM = 512, meaning that 512 bytes (ie. 128 words) are reserved from 0x50000000 for a ULP program, and anything with the RTC_DATA_ATTR attribute comes just after that (ie. 0x50000200, as you noticed). There is 8K of RTC slow memory available in total.

If I understand correctly (I don't think I have), it sounds like you think you need your ULP program to 'overlap' the location of this variable in order to access it, but you definitely don't want that. The ULP can access it wherever it is in RTC slow memory, you just need to provide the offset to I_ST and I_LD.

You don't even need to use RTC_DATA_ATTR (and it's probably best not to, so you know consistently which data is where). Take a look at how sharing memory is handled here: https://github.com/espressif/esp-idf/bl ... ple_main.c
ULP_DATA_OFFSET is defined as the starting location of data; then the ULP and SoC can read (I_LD and ulp_data_read, respectively) and write (I_ST and ulp_data_write) using this.

Also remember that the little ULP only does 16 bits. Your 32 bit counter will have some junk in the upper 16 bits if you I_ST there.

[psych_uk]

Thanks for the reply.

I know the LD and ST operands only do 16 bits, but they need 32bit memory offsets in the ULP, so the counter size was deliberate, the main program would simply mask those pesky upper bits.

As for the memory issue, I already had a system which would just read the memory at the start, I just assumed having the RTC_DATA_ATTR was a cleaner solution (and is actually the preferred and recommended method in the docs).

The attribute actually refers to the 'rtc.data' section of the compiled program (if you follow the defines), and this, as you correctly stated, is declared after the 'rtc.text' section, 'text' sections are assembly. Ironically, if you create a define to this 'text' section you get 0x400C000. Its all very confusing.

I like the static inline method in the link you mentioned, it's quite clean and I can just put all the offsets into a enum and use the enums in both the main program and the ULP, then I'll just count the enums and offset the ULP program by that many words.

That being said, if anyone knows how the 'fake' the attribute (or create a new attribute) to read and write at 0x5000000 I would be most grateful.