[solved] Unknown error uploading EtherCAT firmware to cifX50
Hello,
I'm trying to use the CIFX 50-RE PCI card in a PC with Linux OS as an EtherCAT slave.
Therefore I've written a small PCI driver which maps the card io memory (the NetX DPM) into user space. Now I'm trying to get the card to work with the Hilscher cifX C-Toolkit (V0.911), which I've extended as proposed in the documentation with the implementation of OS dependent and toolkit user functions for Linux.
So far the first steps of the cards initialization process are carried out fine (card reset is beeing performed, the 2nd stage PCI bootloader gets downloaded and started).
After that the init process is aborted while the toolkit is trying to download the EtherCAT firmware to the NetX. This happens when the toolkit sends the packet with the firmware download request (MID_SYS_FILE_DOWNLOAD_REQ command) to the system mailbox in the DPM. The actual sending seems to work and after some handshake handling stuff the confirm packet is read. This confirmation packet contains an error code in the status field (instead of 0x0), which I think is generated by the 2nd stage bootloader, but I could find its meaning nowhere in the documentation.
This is the packet the toolkit writes to the system mailbox:
Dest: 0x00000000 Src: 0x08052054 DestID: 0x00000000 SrcID: 0x00000000 Len: 0x0000001f Id: 0x00000001 Stat: 0x00000000 Cmd: 0x00001e62 Ext: 0x00000080 Rout: 0x00000000 Data: 02 00 00 00 4c 00 00 00 c0 45 03 00 00 00 00 00 0d 00 00 00 65 74 68 65 72 63 61 74 2e 6d 6f
And this is the confirmation packet from the receive mailbox:
Dest: 0x00000000 Src: 0x08052054 DestID: 0x00000000 SrcID: 0x00000000 Len: 0x00000004 Id: 0x00000001 Stat: 0xc02b4444 Cmd: 0x00001e63 Ext: 0x00000080 Rout: 0x08052054 Data: 02 00 00 00
Thats why my question: What is the meaning of this error code: 0xc02b4444? Or any ideas what I might have done wrong or overlooked while porting the c toolkit to Linux which could cause such an effect?
Best regards
Thomas Elste
PS(@admin): Not sure if this is the right category I'm writing in, so please move my post if not.
Hi AJ,
ok, I will give V0.921 a try. 2 or 3 days ago only V0.911 was available for download. The Version I started with (from the CD that came with the card) haven't even got a version number :).
Adjusting will take a little time. There are some more OS dependent functions to implement I see at a first glance. When I've got results concerning my problem I'll report back.
Thanks
Thomas
Hi,
new toolkit version (V0921), same problem. After some adjustments I've tried the latest toolkit version with my card. It fails downloading the firmware to the netX with the same error code as before.
Nevertheless, I think I've found the meaning of this error code in the header TLR_Results.h from the "Win2000/XP Driver-Kit for cifX". This one isn't included in the toolkit. According to the error defines in this header, these are the steps and resulting errors of the toolkit trying to download the firmware file:
RCX_FILE_GET_MD5_REQ -> TLR_E_RCX_FILE_TRANSFER_PACKET_INVALID RCX_DIR_LIST_REQ -> TLR_E_RCX_MID_FAT_NO_INIT RCX_FILE_DOWNLOAD_REQ -> TLR_E_RCX_FILE_TRANSFER_PACKET_INVALID
Noticing a different size 2nd stage bootloader file in the XP Driver-Kit I tried this one, too. Thus the last error changed into:
RCX_FILE_DOWNLOAD_REQ -> TLR_E_RCX_FILE_NAME_INVALID
The packets send to the card are looking fine to me (according to the documentation, mainly the DPM Interface Manual). I can only assume that there is still a version conflict between toolkit and/or 2nd stage bootloader and/or firmware. So here is an exact listing of the files I'm using resp. trying to use:
Toolkit: comX_cifX_ToolkitV0921.zip Bootloader from the CD i've got with the cifX card (64924 Bytes): NXCIF50-RTE.bin (md5-hash: b8d15df231d2d72c05bed868278cb734) (This one throws the FILE_TRANSFER_PACKET_INVALID error) Bootloader from the Win2000/XP Driver-Kit (B0.920) for cifX (64444 Bytes): NXCIF50-RTE.bin (md5-hash: 23ebb25bc90fca55e7830c5ac0c9b840) (This on throws the RCX_FILE_NAME_INVALID error) Firmware (214464 Bytes): ethercat.mod (md5-hash: 3e3756aabdfa68ab593b71b05f9ea9d8)
So I'm at a loss what to do next.
Best regards
Thomas
M T
Hilscher Gesellschaft für Systemautomation mbH
Hi th_elste,
sorry for the late reply.
From your dumps it looks like the structure packing did not work in your case. The download packet consists of the following elements:
8 dwords + 2 words in the data portion, with the filenaming following directly. In your dump 2 padding bytes (00) are added which only happens if the attribute packed is missing in the GNU compiler.
I think your are missing the define CIFX_TOOLKIT during compilation which should set the packing accordingly. See the following snippet from rcX_Public.h
#ifdef CIFX_TOOLKIT #define __TKITPACKED_PRE __PACKED_PRE #define __TKITPACKED_POST __PACKED_POST #else #define __TKITPACKED_PRE #define __TKITPACKED_POST #endif
Regards
MT
Hi MT,
thank you for this hint. I should've read the VC project file more carefully, before writing my Makefiles.
With CIFX_TOOLKIT defined the firmware download starts now :). But often it gets aborted at a random point with a CIFX_DEV_GET_NO_PACKET error. Maybe some timing issues. I'll have to check this.
A successful download is producing this output:
New device is a PCI device and will be reset! Bootloader was downloaded and started successfully! Firmware download, checking / starting: CHANNEL #0, 1 file(s) transmit count: 214464 Successfully downloaded the firmware to device '/etc/netx/ethercat.mod'! Configuration download, checking / starting: CHANNEL#0, 0 file(s)! System channel is READY! Successfully started firmware! NO CHANNEL INFORMATION FOUND, No devices created! --snip--
Still no channel info could be read. But before addressing this error I'll try to get the firmware download stable.
And another question is: Does a configuration file have to be downloaded, too (for an EtherCat slave)?
Thanks again for your help
Thomas
M T
Hilscher Gesellschaft für Systemautomation mbH
Good to hear, it is working now.
The DEV_GET_NO_PACKET really sounds to me like a timing issue. Usually there should be an answer to the packet, at least a negative one if something went wrong. The timeout inside the toolkit is something about 1 second. Maybe you implemented the OS_GetMilliSeconds() with a wrong unit like microseconds. This is just a guess.
You can use warmstart parameters for every slave fieldbus stack. So no need for a configuration file. The warmstart packets can be generated by the Windows cifX Setup tool, or you may take a look at the protocol interface manuals that should describe those packets more closely.
the NO Channel information looks to me, as if the firmware was not started correctly, or maybe it was not yet ready, even if the ready flag was detected. This is just speculative and is just a place to look more closer into it. Or maybe the System Channels ready signal was seen before the actual startup of the firmware/module.
Regards
MT
Hi,
Maybe you implemented the OS_GetMilliSeconds() with a wrong unit like microseconds.
this function was top of my bug search list, too. And apparently my implementation was not always working correctly. Using a much simpler approach, the firmware gets now every time downloaded completly.
And after fixing OS_GetMilliSecCounter(), channel info reading and most of the other demos also seem to work now.
Thanks for your help :). If I encounter another problem I'll start a new thread.
Thomas
Andreas Jacob
Hilscher Gesellschaft fuer Systemautomation mbH
Hi th_elste,
for me it looks like you are using the new firmwares which are not anymore working with your used toolkit version.
There are some file download functions changed.
Please visit the Hilscher web page for the latest version of the toolkit.