Chained Slicekits only start from debugger Topic is solved

[hegt]

Hello togheter,

I made a simple program running on the slicekit on 4 cores:


on tile[0]: port p0 = XS1_PORT_4A;
on tile[1]: port p1 = XS1_PORT_4A;
on tile[2]: port p2 = XS1_PORT_4A;
on tile[3]: port p3 = XS1_PORT_4A;


void process(port p){
    int i = 0;
    while(1){
        i = ~i;
        delay_milliseconds(100);
        p<: i;
    }
}


// Program entry point
int main(void) {

    par
    {
          on tile[3]: process(p3);
          on tile[2]: process(p2);
          on tile[1]: process(p1);
          on tile[0]: process(p0);
    }
    return 0;

}

 

I am using the xn file described in:

http://www.xcore.com/questions/2633/xn- ... -slicekits

Now I have the problem, that the program starts perfectly in debug mode. When I flash the program to the boards, it seems to hang on startup and the program never really starts. Do I have to put the boards in some other boot state? How?

[srinie]

If not already had a look, can you check this?

http://www.xcore.com/forum/viewtopic.ph ... boot+state

 

[hegt]

Allright, thanks. I understand that there is a difference in the boot procedure. But what/where do I have to change to have the boards in the correct state. Where do I change the MSEL_IN pin?

[myndideal]

hi, msel_in (pin3 of the xsys header) is handled by the xmos xtag2 automatically. It have to be on high "1" by default,  which means the device starts booting from spi, and only if you lauch/download the code from jtag have to be low for a while... But I dont believe if it is wrong...  Did you tried to disconnect the xtag2? (This let the msel goes to high too.) When xtag2 is not connected, and the board still not booting from spi, there have to be some other issue...

Running codes from the IDE is simply, because the device is just waiting for jtag, and jtag protocol is just works... But when we try to booting in a stand-alone system (I mean in real life/without jtag) there are a lot of variations, and several problematic case could be happend.

You can debug it, with xrun --dump-state yourapplication.xe after the board theoretically rebooted from SPI already, even if cpu doesn't arrived to your main() function.

Obviously the tile[0] : core[0] will be on an exception and others just waiting for this one endless. Probably the PC's are still pointing to a ROM address (0xFFFFXXXX), which means the booting process can not be finished/started some reason.  The following post could be helpful :

http://www.xcore.com/questions/3233/wha ... debug-boot

[hegt]

Thanks for the answers so far. I made a forum entry to further discuss the problem:

http://www.xcore.com/forum/viewtopic.php?f=26&t=3393