app_can_demo example issues. Program "crashes" on Tile[1

Technical questions regarding the XTC tools and programming with XMOS.
User avatar
emh203
Junior Member
Posts: 5
Joined: Tue Mar 25, 2014 7:01 pm

app_can_demo example issues. Program "crashes" on Tile[1

Post by emh203 »

Hello:

I am very new to xmos and and currently doing prototype evaluation. I come from the world of FPGAs and MCUs so I am trying to be patient. :-)

I loaded up the example code for the app_can_demo to try out the CAN bus functionality. I have a slice kit and my own custom PCB with hardware.

The default program does compile and run however I need to change the I/Os for my PCB so I modified line 6 of the program to select my I/O on tile[1]:

on tile[1]: can_ports p = { XS1_PORT_1E, XS1_PORT_1H, XS1_CLKBLK_1 };

I also edited the main par statement:

par {

on tile[1]: application(c_rx_tx);
on tile[1]: can_server(p, c_rx_tx);

}


When I build and run the program the debugger will always stop on the line 28):

is_response_to_notification = inuchar(c);

in mutual_thread_comm.xc


Any ideas? Is it possible to relocate this code onto tile 1? I was successful on some other projects examples (i.e. SPI) and was able to get stuff working.


User avatar
Bianco
XCore Expert
Posts: 754
Joined: Thu Dec 10, 2009 6:56 pm
Contact:

Post by Bianco »

Hi,

inuchar() performs a read on a chanend, if no data is available the thread in execution will be blocked until there is data available.

I think your program is blocking on line 40 of this file: https://github.com/xcore/sc_util/blob/m ... ad_comm.xc

If the blocked thread is the can_server() function it likely means that you have removed some calls to functions in the module_mutual_thread_comm in your application() function or if you wrote the application() function from scratch you will have to make calls from functions in module_mutual_thread_comm speaking the protocol that can_server() understands
User avatar
emh203
Junior Member
Posts: 5
Joined: Tue Mar 25, 2014 7:01 pm

Post by emh203 »

Bianco:

Keep in mind I am using the demo code as is except for the port and tile changes. (Moving the CAN ports and threads to tile 1)

THere is something more violent going on here. WHen I say crash I get the error:

xrun: Program received signal ET_ILLEGAL_RESOURCE, Resource exception.
[Switching to tile[1] core[0]]
User avatar
Bianco
XCore Expert
Posts: 754
Joined: Thu Dec 10, 2009 6:56 pm
Contact:

Post by Bianco »

I cannot tell why the application crashes with this amount of information.
If the two threads aren't sharing any memory which is usually the case, they can be moved to different tiles.

It would help to know if the same behaviour exhibits in the xmos simulator.
That would be an easy way to track down because it is convenient to examine a large instruction trace.
vinith
Junior Member
Posts: 5
Joined: Wed Jul 31, 2013 6:44 am

Post by vinith »

Hello emh203,
The 'app_can_demo' works with the sliceKIT L16 core board + ISBUS sliceCARD. Of course, it can be changed to work with other hardware. The XA-SK-ISBUS sliceCARD has a Maxim 3051 CAN transceiver which requires an RS signal. This signal must be pulled low for High speed operation of the Maxim 3051.

In the application (app_can_demo.xc), this is done by the 'shutdown' port. In the application, this is pulled low before calling the can_server(). If you are using the ISBUS sliceCARD, then the ports can be modified as follows:

// ISBUS sliceCARD connected to square slot on core board
//on tile[1]: can_ports p = { XS1_PORT_1F, XS1_PORT_1G, XS1_CLKBLK_1 };
//on tile[1]: port shutdown = XS1_PORT_4A;

// ISBUS sliceCARD connected to circle slot on core board
//on tile[1]: can_ports p = { XS1_PORT_1L, XS1_PORT_1I, XS1_CLKBLK_1 };
//on tile[1]: port shutdown = XS1_PORT_4E;

However, I read that you are using a custom PCB. Does it have the same (or similar) Maxim 3051 transceiver?
User avatar
emh203
Junior Member
Posts: 5
Joined: Tue Mar 25, 2014 7:01 pm

Post by emh203 »

Bianco:

I'll give that a try. I can post the code (although it a simple mode from what comes with the tools).


vinith:

I an using a TI can transceiver but this is not the issue. I understand the function of the RS port but I believe this issue is something going on internal to XMOS device as the program is crashing.
vinith
Junior Member
Posts: 5
Joined: Wed Jul 31, 2013 6:44 am

Post by vinith »

Hi emh203,
May I know which TI's CAN transceiver are you using (part number, if possible)?
Regards,
Vinith
User avatar
emh203
Junior Member
Posts: 5
Joined: Tue Mar 25, 2014 7:01 pm

Post by emh203 »

SN65HVD230
vinith
Junior Member
Posts: 5
Joined: Wed Jul 31, 2013 6:44 am

Post by vinith »

Hello emh203,
The SN65HVD230 too has an RS pin. Are you pulling it low?
In the can_conf.h, the 'CAN_CLOCK_DIVIDE' is defined as 2 (in as is code) which results in 500 kbps CAN rate. Is this the rate, you are looking for?
Regards,
Vinith
User avatar
emh203
Junior Member
Posts: 5
Joined: Tue Mar 25, 2014 7:01 pm

Post by emh203 »

Vinith:

Yes, RS is low. Bit rate is fine. The issue is NOT with the transciever, rather the core for the CAN code.

Also, This problem also exists on the official CAN dev tool. You simply cannot move this code to other pins/tiles without the system crashing.

We eventually punted. I noticed that the can code it uses quite a bit of assembly. It is simply too much of a time investment to write our own CAN module from scratch. Between the constant crashes of the CPU, xmos tools and the speed of the I/O we had to use a different IC. We ended up going back to an ARM MCU + gate array. The xmos is just too risky at this point (given how easy it is to bring to the the IC to its knees with *reference* code) That and the power consumption is awful.

I am sure there is a a good application for the xmos but not anything that requires high reliability/fault tolerance. Hopefully I'll get another shot on a another project that better fits the capabilities of the device.
Post Reply