Running a program on a core

[Suleyman]

Hi,

I use the board with the arm processor and sdk 4.13.03.30 (sdk 5 was causing too much trouble). I load different programs on different cores and I use 15 cores. While loading I use e_true as the start parameter. I use a piece of shared memory as a Mailbox to synchronize the cores. (All cores set a predefined address on the shared memory to indicate that they are ready.) There are interesting things going on.

-First of all, some of the cores seem not to be running. (Usually the cores which are loaded as last are not running. When I change the orders, the ones, which were previously in the last and not running, starts running but then there are some others which does not want to run. And yes, they are again the new last ones.) I tried using e_false and afterwards e_start() - didn't work. I tried e_true and afterwards e_start() - didn't work.

- Sometimes the cores would run the program even if I set the start parameter as e_false.
- Sometimes the cores would run the program even if I remove the e_load();

I tried to debug but I don't know how to debug an application where you have multiple cores and the host core. I could connect only to the first core and debug it but that didn't help with anything. It seems like the host and the other cores were not running.

My host start-up code sequence is:
e_set_host_verbosity()
e_init()
e_reset_system()
e_alloc()
e_open()
-reset some arrays in the shared memory
-read a few integers from a file and write to the shared memory
-load the cores
-wait for the cores to set an array in the shared memory (each core sets an element of the array with the size of 15)
(At each run, a few elements are not set and they are not always the same ones)
....
- some other stuff

I did a lot of tests about the address of the array in the shared memory. It seems to be okay.
Any ideas what is going on?

Regards,

[Suleyman]

I set the start parameter (in the call for e_load function) to e_false for all cores. When all the cores were loaded, I started all of them with e_start() and now they all seem to be working. Interesting.

[mhonman]

If your mailbox area is mapped to shared RAM via a SECTION directive, the executable file will include pre-initialised data for this area.
Thus as each core program is loaded the mailbox area gets overwritten by the initial data from the executable file.

If this is how you are managing the shared RAM, it would certainly make a difference between loading the cores with immediate start, and only starting the cores after all have been loaded.

IMO the best work-around is to pre-initialise the base address of the mailbox area in each core program, and have the host program explicitly initialise the mailboxes prior to loading any cores. Of course then you have to deal with all the fun (not) of conversion between Epiphany and host pointers - so try to lay out the mailbox area as one big structure rather than a typical C pointer-intensive data structure.

The other challenge awaiting you with the present SDK is that the standard linker scripts all place external-RAM code sections starting from the base of the external RAM. Thus if two core programs have different code in external RAM, the external-RAM code of the most recently loaded core program will overwrite that of those loaded earlier. Even if you use the same program on all cores, there is the risk of unexpected results from non-reentrant functions, e.g. ones that define local static variables.

At present e-core programs do have separate heap spaces in external RAM (setup by the program loader rather than the linker) and stack space should be in internal RAM.

[Suleyman]

[mhonman]

[ysapir]

The eSDK provides command-line tools for probing the Epiphany chip. Try the e-read utility.