no return value from epiphany core

[howardhh]

[notzed]

Your code is probably just crashing.

Try commenting out bits until you get a positive response and then work backwards.

[howardhh]

Hi notzed,

Thanks for your responding. As what I said in my another post ().
I suspect the program in the epiphany cores isn't executed at all, because I have commented everything except the "d" flag, but I still can't get the return value from "d".

[cmcconnell]

I think the use of the hard-coded 0x7000 address might be the issue. Did you copy the ldf file from the dotproduct example? Even if you did, there may still be a problem - see the discussion of the same thing with regard to the matmul example : viewtopic.php?f=23&t=1666&p=10322&sid=fa1b3f351f1760099defae9d261157c2#p10322

It might be better to follow an example that uses a mailbox in shared memory to communicate between Epiphany and ARM, rather than an area of the Epiphany core's memory which might be being clobbered by the stack, or corrupted in some other way.

[howardhh]

Thank you, cmc!

But I still want to know why my program can't do what "dotproduct" has done, since they are quite similar. I also devided "dotproduct" into two parts, main function and subfunction, it also works fine...but mine...

[notzed]

It wont have anything to do with using a subfunction unless you just have broken code.

Maybe you have more code on-core and it's clobbering that address, or defined large arrays in the stack which are clobbering everything.

Only you know this because you haven't provided enough information, we can only guess.

[cmcconnell]

When I asked if you had copied the ldf file, I was assuming that dotproduct, created a special ldf (like matmul does), but that's not the case, it just uses internal.ldf.

Having had a quick look, I see it creates four pointers - a,b,c,d - associated with specific addresses. Presumably that works because the addresses were chosen to be well away from the stack and other areas where the compiler/linker will be placing code and/or variables. (And it's such a simple program that there are no other variables, and hardly any code.)

But that seems like a very bad idea as a template for larger scale development. There are bound to be problems as the program gets bigger. If you do need to share or split data between cores (rather than just with the ARM), there has to be a better way. The matmul example has a 'shared_core' section, defined in the ldf, but there may be an issue with how that is being done, as described in the thread I referenced earlier.

If your code is as stripped down as dotproduct and yet failing, then I guess it can't be the stack that is causing the problem. The IDLE instruction at the end might be important, preventing the program from exiting, so you should make sure you keep that in place.

Your best approach would probably be to take the working dotproduct code and modify it step by step, until you find the change which breaks it.

Also, have you actually determined that the values of d being read by the host are all zero (e.g., using printf() ), or are you just assuming that? If random garbage is being returned, then the test (all_done==16) will never be true. You could make all_done unsigned, and change the test to (all_done >= 16). Then add assert(all_done==16) to test for nonsense results.

[howardhh]

Thank you very much for the suggestion, cmc!

I have sovled the problem by writting values into more sparse address. The "done" flag can be returned to the host.