I am trying to get CAN communication running via an external SBC (TLE9263) board.
Microcontroller: S32K312
Ext. SBC board: TLE9263_EVB_2
Without SBC, i.e., using a standard external CAN transceiver TJA1057GT, CAN communication is running.
With SBC, some messages are received once, but then the SBC transceiver goes down, and CANIF_E_FATAL Det error occurs (Call Stack).
I configured the SBC registers as follows: SBC registers configuration
The following values are observed on the SPI-MOSI signal:
41 00 - SUP_STAT_1
82 00 - HW_CTRL
81 1F - M_S_CTRL
84 07 - BUS_CTRL_1
85 00 - BUS_CTRL_2
83 82 - WD_CTRL
The above observed values are expected in my opinion. What could be the cause of communication not working?
Additionally (not sure if this is relevant), the Fail Output LEDs on the TLE9263 board, FO1 and FO3 are ON as soon as the board is powered, and FO2 is blinking, and this status of the LEDs remains the same when the software is run.
Related
I am developing a program to connect my PC to Omron CJ2M PLC to send read / write commands.
As per my understanding, Omron PLCs can be communicated over 3 methods:
1) Hostlink,
2) FINS, (TCP or UDP) and
3) EIP.
My requirement here is to connect CJ2M through EIP, and send Read/Write commands over EIP(CIP) protocol.
Initally EIP communication needs to send 2 requests:
1) List Services and 2) Register Sessions
Register Sessions returns a handle which should be used in further communication over EIP.
I am successfully able to send List Services, Register Session and Forward Open (RR Data) and these are successfully replied by the Omron PLC. There is no problem in these 3 requests/responses.
Now I want to know which command/service need to be used to read the memory area of Omron (say DR 20 memory address).
I am sending service code 0x4d over RR Data, but it says "Vendor Specific Error" and then connection gets terminated.
I need protocol specification for Omron EIP or wireshark logs or some sniffed packets where a request / response is captured over EIP communication from PC to Omron PLC (no fins, no hostlink).
We can send requests to Omron EIP using "Send Unit Data" with service code 0x4d.
This service (0x4d) is used to send write request as per EIP documentation, but we can insert the Omron specific commands (FINS) to read the memory areas in command specific data.
0000 00 00 00 00 00 80 0e 00 01 00 80 00 02 00 00 00
0010 00 00 00 12 01 01 82 00 00 00 00 01
i am using a A20 OLinuXino Micro 4GB from Olimex with Debian on SD Card.
I want to use the GPIOs and have some short question about the configuration of the GPIOs. The GPIO-1 connector on the board has pins numbered from 1 to 39. In the manual I have entries like that:
Pin # | Signal name | Processor pin
23 | PG9 | C19
...
39 | LRADC1 | AB22
In the fex file, I find this:
[gpio_para]
gpio_used = 1
gpio_num = 64
...
gpio_pin_10 = port:PG09<0><default><default><default>
How is defined that the processor pin C19 is routed to port PG9?
And port means exactly what?
How is defined that the port PG9 is routed to pin23 of the connector?
Can the gpio_pin_10 designation be chosen arbitrarily?
At the end I would like to use the LRADC1, to sample a signal, but the fex file doesn't have any LRADC1 entry. Why is that?
Maybe somebody could answer may questions in 2 or 3 sentences so it makes sense to the rest of what I read. Thanks!
Please take a look at A20-OLinuXino-MICRO schematics. You can find wiring:
PG09 - C19
PG10 - D18
PG11 - C18
(...)
In mentioned schematics is also section GPIO EXTENSION in which you can find which A20 SoC pin is assigned to which GPIO:
PG09 - 23 GPIO-1
PG10 - 25 GPIO-1
According to Wikipedia:
A GPIO port is a group of GPIO pins (typically 8 GPIO pins) arranged in a group and controlled as a group.
Mapping between physical pin and pin exposed through fex file to operating system is arbitrary. Of course to get correct results you have to assign GPIO ping not. I don't think that fex compiler check anything other then syntax.
In case LRADC0 (again schematics) it us used for buttons (vol +/-, menu, search, ...) and LRADC1 is exposed through GPIO-1 pin 39.
I have a VW Golf 4, which is quite old and talks KWP 2000 (ISO 9141) on its CAN bus. I use a dongle powered by ELM 327, connected to the OBD-2 port of the car.
I am trying to send messages individually to each ECU. I tried to change the header of the messages:
AT SH 48 XX F1 (I hoped XX would be the ECU ID; 48 is the flag for "use physical addressing"). Any command I issue (e.g. tried 3E for "tester present") returns NO DATA (I disabled automatic timeouts and set the timeout to maximum value).
Is there a way to send messages directly to the ECU? I am not interested in the set of data provided via OBD-2, neither do I want to re-flash the ECUs. At the moment I just try to find out which ECUs are available on the bus.
Thanks!
VW works on Transport Protocol TP 2.0, hence you need to initialize with 0x200 header.
https://jazdw.net/tp20
See above link for more info.
when I send an API ND command to a remote endpoint I get ???
When I send an API ND command from a VB program using the following packet;
7E 00 05 08 01 4E 44 00 64
I get;
7E 05 3F 14 E4 41 3F
Its a response -- but not as I know it. Neither the checksum "3F" or command length "05" are comprehensible to me. On the other hand if I wait for more bytes by setting "Serialport1.ReceivedBytesThreshold" (threshold: 10 bytes in buffer > event is fired) to 10 the "SerialPort1.ReadExisting()" statement times out. Any suggestions for decoding? Both coordinator and endpoint are XBEE PRO S2Bs.
I don't think it makes sense to send ATND as a remote AT command, and it will probably be ignored on the remote node, or trigger node discovery at that node with the responses staying local.
It looks like your response is possibly dropping null bytes (0x00), like the MSB of length, and one more in the packet itself. I'm not familiar with a frame type of 0x3F though -- is it documented for that XBee module you're using?
After a node discovery, you should see multiple AT Response frames (type 0x88?) come back over some time (based on ATNT, I believe), until you get one with a short payload (indicating discovery is complete).
I'm trying to connect two xbee's pro s2 and make them communicate with each other in API Mode (further, I will use more end and router devices). Basically, I have a xbee coordinator plugged on my PC through digi adapter and I have other xbee connected to a PIC18f25. Right now I'm working on send and receive data from one to another and vice versa.
When I connect both on the usb adapter, the communication works just fine (I can send and receive data from/to both devices). However, when I try to work with the previous configuration, I find it impossible to get the data, which is sent from the coordinator, from the end device with the PIC. Here goes the data that I'm trying to send:
From Coord 2 EndD - 7E 00 13 10 01 00 13 A2 00 40 8D 5A 8B FF FE 00 00 48 65 6C 6C 6F 96
From EndD 2 Coord - 7E 00 13 10 01 00 00 00 00 00 00 00 00 FF FE 00 00 48 65 6C 6C 6F FD
I think it's usable to say that when I try to send the data from the PIC, through end device, to coordinator, it works.
I wonder if the problem relies on my code, which can be found below:
#include <18F25K20.h>
#device adc =10
#device ICD=TRUE
#FUSES noWDT // Watch Dog Timer
#fuses LP //low power crystal
#FUSES XT //Crystal osc <= 4mhz
#fuses BROWNOUT_SW //Brownout enabled during operation, disabled during SLEEP
#FUSES NOPROTECT //Code not protected from reading
#FUSES BROWNOUT //brownout reset
#FUSES BORV27 //Brownout reset at 2.7V
#FUSES NOPUT //Power Up Timer
#FUSES NOCPD //No EE protection
#FUSES STVREN //Stack full/underflow will cause reset
#FUSES noDEBUG //No Debug mode for ICD
#FUSES noLVP //Low Voltage Programming on B3(PIC16) or B5(PIC18)
#FUSES NOWRT //Program memory not write protected
#FUSES NOWRTD //Data EEPROM not write protected
#FUSES noIESO //Internal External Switch Over mode enabled
#FUSES FCMEN //Fail-safe clock monitor enabled
#FUSES NOPBADEN //PORTB pins are configured as analog input channels on RESET
#FUSES NOWRTC //configuration not registers write protected
#FUSES NOWRTB //Boot block not write protected
#FUSES NOEBTR //Memory not protected from table reads
#FUSES NOEBTRB //Boot block not protected from table reads
#FUSES NOCPB //No Boot Block code protection
#FUSES LPT1OSC //Timer1 configured for low-power operation
#FUSES MCLR //Master Clear pin enabled
#FUSES XINST //Extended set extension and Indexed Addressing mode enabled*/
#use delay(clock = 4000000) /* Clock definition */
#use rs232(BAUD = 9600, XMIT = PIN_C6, RCV = PIN_C7) /* ZigBee and PIC Communication */
int16 var;
byte var2=0x00;
long timeout;
void main() {
output_low(PIN_C5); // Turning on Xbee
delay_ms(10);
while(1) {
delay_ms(100);
output_high(PIN_C0); // TESTE
delay_ms(100);
output_low(PIN_C0);
timeout=0;
while(!kbhit()&&(++timeout<5000)) delay_us(5);
if(kbhit()){
output_high(PIN_C0);
delay_ms(10);
output_low(PIN_C0);
delay_ms(10);
output_high(PIN_C0);
delay_ms(10);
output_low(PIN_C0);
delay_ms(10);
output_high(PIN_C0);
delay_ms(10);
output_low(PIN_C0);
var2 = getc();
delay_ms(1000);
}
/* Data which is succesfully sent to coordinator
putc(0x7E);
putc(0x00);
putc(0x13);
putc(0x10);
putc(0x01);
putc(0x00);
putc(0x00);
putc(0x00);
putc(0x00);
putc(0x00);
putc(0x00);
putc(0x00);
putc(0x00);
putc(0xFF);
putc(0xFE);
putc(0x00);
putc(0x00);
putc(0x48);
putc(0x65);
putc(0x6C);
putc(0x6C);
putc(0x6F);
putc(0xFD);*/
}
}
The program is supposed to blink a LED (PIN_C0) with 100 ms, and blink it faster if any data enter in the PIC. However it doesn't work as I planned and I have no clue why.
Any help will be appreciated.
Thank you all in advance,
Regards.
You know that a lot of pieces are working at this point. If the PIC is sending frames to the XBee module that the coordinator receives, then:
You have the correct baud rate.
You at least have the PIC Tx hooked correctly to the XBee Rx.
The XBee module has power and is running.
The XBee module is joined to the coordinator's network.
The RESET line of the XBee module is asserted correctly.
Is it possible that you have hardware handshaking enabled (ATD6=1) on the XBee module, so it's failing to send to the PIC due to it not asserting RTS?
Can you connect a standard serial cable to the PIC (instead of the XBee), and confirm that data sent in from a terminal program triggers your flashing, and that the terminal program sees the sent frame?
Can you use an XBee interface that flashes LEDs on Tx and Rx so you can visually see if data is coming through?