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.
app_can_demo example issues. Program "crashes" on Tile[1
-
- Junior Member
- Posts: 5
- Joined: Tue Mar 25, 2014 7:01 pm
-
- XCore Expert
- Posts: 754
- Joined: Thu Dec 10, 2009 6:56 pm
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
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
-
- Junior Member
- Posts: 5
- Joined: Tue Mar 25, 2014 7:01 pm
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]]
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]]
-
- XCore Expert
- Posts: 754
- Joined: Thu Dec 10, 2009 6:56 pm
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.
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.
-
- Junior Member
- Posts: 5
- Joined: Wed Jul 31, 2013 6:44 am
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?
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?
-
- Junior Member
- Posts: 5
- Joined: Tue Mar 25, 2014 7:01 pm
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.
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.
-
- Junior Member
- Posts: 5
- Joined: Wed Jul 31, 2013 6:44 am
Hi emh203,
May I know which TI's CAN transceiver are you using (part number, if possible)?
Regards,
Vinith
May I know which TI's CAN transceiver are you using (part number, if possible)?
Regards,
Vinith
-
- Junior Member
- Posts: 5
- Joined: Tue Mar 25, 2014 7:01 pm
-
- Junior Member
- Posts: 5
- Joined: Wed Jul 31, 2013 6:44 am
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
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
-
- Junior Member
- Posts: 5
- Joined: Tue Mar 25, 2014 7:01 pm
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.
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.