Running into "Signal 'ET_ECALL' received" on using SPI Lib Topic is solved

Technical questions regarding the XTC tools and programming with XMOS.
DemoniacMilk
XCore Addict
Posts: 191
Joined: Tue Jul 05, 2016 2:19 pm

Running into "Signal 'ET_ECALL' received" on using SPI Lib

Post by DemoniacMilk »

Hey everyone,

I am currently trying to implement SPI on an xCore-200 (using the explorer kit), using the async SPI Master as found in the öib_spi(v3.02) provided by xmos.

On trying to add SPI functionality to the project, i got issues with the programm halting right after startup with an ET_ECALL Signal, highlighting lines in spi_asyn.xc. From what i have read, this is caused by pointer/array operations out of bounds.

I have created a smaller project, starting only the spi_master_async() thread and a second thread, that keeps sending an 8 byte array periodically.

Code: Select all

#include "spi.h"


out buffered port:32   p_sclk  = on tile[0]: XS1_PORT_1A;       // D00
out port               p_ss[1] = on tile[0]: {XS1_PORT_1O};     // D38
in buffered port:32    p_miso  = on tile[0]: XS1_PORT_1B;       // D01
out buffered port:32   p_mosi  = on tile[0]: XS1_PORT_1P;       // D39

int main(){
    interface spi_master_async_if spi_if[1];

    par {
        on tile[0]: spiTestAppliction(spi_if[0]);

        on tile[0]: spi_master_async(spi_if, 1,
                p_sclk, p_mosi, p_miso, p_ss, 1,
                spiClk0, spiClk1);
    }
    return 0;
}
the test application looks like this:

Code: Select all

void spiTestAppliction(client interface spi_master_async_if spi_if){
    timer t;
    unsigned int time;

    t :> time;

    unsigned char ucaTx[8] = {1,2,3,4,5,6,7,8};
    unsigned char ucaRx[8];

    unsigned char * movable ucpTx = &ucaTx[0];
    unsigned char * movable ucpRx = &ucaRx[0];

    while(1){
        select{
            case t when timerafter(time) :> void:
                spi_if.begin_transaction(0, 1000, SPI_MODE_1);
                spi_if.init_transfer_array_8(move(ucpTx), move(ucpRx), 8);
                break;
            case spi_if.transfer_complete():
                spi_if.end_transaction(200);
                break;
        }
    }
}
on running the programm, i get the ET_ECALL signal with the following line being highlighted inside the spy_async.xc file:

Code: Select all

init_init_transfer_array_8(sclk, mosi, miso, active_mode, cb1, ((uint8_t*movable)buffer_tx)[0]);
Did i get the idea/syntax of movable pointers correctly?
Do you have an idea, what is going wrong?

Thanks in advance,
Regards


View Solution
DemoniacMilk
XCore Addict
Posts: 191
Joined: Tue Jul 05, 2016 2:19 pm

Post by DemoniacMilk »

Ou, I think i found it.
I did not retrieve the pointers after the transfers completion, so I guess the programm stopped on the second run.

I changed the code to

Code: Select all

    while(1){
        select{
            case t when timerafter(time) :> void:
                spi_if.begin_transaction(0, 1000, SPI_MODE_1);
                spi_if.init_transfer_array_8(move(ucpTx), move(ucpRx), 8);

                select {
                    case spi_if.transfer_complete():
                        spi_if.retrieve_transfer_buffers_8(ucpTx, ucpRx);
                        break;
                }
                spi_if.end_transaction(200);
                break;
        }
    }
I'd like to check the SPI bus with help of a logic analyzier/scope, but the pin labeling is super confusing to me. Are the pin numbers in the initial post (comments on pin assignment) correct?
User avatar
infiniteimprobability
XCore Legend
Posts: 1126
Joined: Thu May 27, 2010 10:08 am

Post by infiniteimprobability »

Are the pin numbers in the initial post (comments on pin assignment) correct?
Yes - they look correct. The best place to plan your pin assignments is using the port map on pages 7/8 of the datasheet https://www.xmos.com/download/private/X ... .10%29.pdf

It can be a little confusing initially - this comes from the fact that there are more port bits than pins, which brings flexibility.

For example, physical pin X0D38 can be driven by either Port 1O0, 8D2 or 16B10 depending on what is enabled.
DemoniacMilk
XCore Addict
Posts: 191
Joined: Tue Jul 05, 2016 2:19 pm

Post by DemoniacMilk »

Yes - they look correct.
I found out that I had connected the analyzer to pins on Tile 1 I/O header instead of Tile 0. SPI is working as intended.

Please correct me if I am wrong: I think each tile has an identical setup of pins/ports of which some may be combined to 4/8/16 bit ports. Some pins are routed to the tile 0/1 headers on the eXplorerKit. The pins routed to the headers are different for each tile, so I might find P1A on the respective header for tile 1, but not for tile 0 ?
User avatar
infiniteimprobability
XCore Legend
Posts: 1126
Joined: Thu May 27, 2010 10:08 am

Post by infiniteimprobability »

I found out that I had connected the analyzer to pins on Tile 1 I/O header instead of Tile 0. SPI is working as intended.
Glad it's working!
Please correct me if I am wrong: I think each tile has an identical setup of pins/ports of which some may be combined to 4/8/16 bit ports.
Not quite, assuming the TQ128, tile 1 has a couple of holes in the portmap - X1D12, X1D13 & X1D22, X1D23, X1D24, X1D25 & X1D34 which are all 1b ports. These ports are lost anyway when enabling USB on tile 1, so it's more I/O efficient to use tile 1 for USB if you can.
Some pins are routed to the tile 0/1 headers on the eXplorerKit. The pins routed to the headers are different for each tile, so I might find P1A on the respective header for tile 1, but not for tile 0
Right - page 5 of this https://www.xmos.com/download/private/x ... 1.2%29.pdf will give you the full details

Targeting I/O on the wrong tile is something we have done at some point. One of those "I swear the code is OK" moments.
DemoniacMilk
XCore Addict
Posts: 191
Joined: Tue Jul 05, 2016 2:19 pm

Post by DemoniacMilk »

Targeting I/O on the wrong tile is something we have done at some point. One of those "I swear the code is OK" moments.
can relate :D thank you for your help!