Using the e_mutex

[Alec]

[ysapir]

"section_core" is a section name created for the matmul example, and can be found in its provided LDF. It is not defined (and thus, being ignored) when linking using the standard LDF files provided in the BSP's.

[Alec]

[ysapir]

Could you please post an SSCCE (*)? It is hard to tell what the host is seeing and what you regard as a deadlock.


(*)

[aolofsson]

Alec,

Note that the address used in the mutex must be a global 32 bit address (even if you are using a mutex location that is within the core you are currently running the program from). 0x0002000 won't work so and using the local memory sections .data_bank0 won't work. The address should be of the format 0x8242000. We will consider a change for the upcoming e-lib API release that will make this more intuitive. The beauty of open source is that we can also show the source code of the function to try to explain what's going on

https://github.com/adapteva/epiphany-li ... tex_lock.s

Andreas

[Alec]

Thanks aolofsson, that removed my deadlock issue. I used e_address_from_coreid() to convert from a local address to a global one, and now the program runs to completion. However, it doesn't seem to be getting mutual exclusion. Attached is a .zip file containing my code and build/run scripts. Correct output should be "Final counter value: 16" but when I run it I get "Final counter value: 1". If I change the mutex's SECTION annotation to ".data_bank0", I get the error I posted a few posts above.

[ysapir]

[Alec]

Ah. Yes, yes it should. I thought I'd reverted that after one of my attempts to get the e_mutex_t to work. It works now, though, thank you and aolofsson very much for your help!

Actually, two quick questions: Why would this not compile if I choose to place the mutex in data bank 0? Is it because it overlaps with other local data that the program needs (as the compile error seems to imply)? Is it best just to never place things into data bank 0?

[ysapir]

There is a problem with LDF(s). Trying to locate data objects on ".data_bank0" creates a contention with the placement on the program code, which is put there as well. The problem is known and hopefully there will be a solution for that soon.