Skip to end of metadata
Go to start of metadata

Board fails to boot into Linux

There are many possible reasons for why a board may not boot.  Below is a list of possible causes and actions to follow.

No power

If LED D9 is not illuminated then there is no power to the board:

  1. Check the power connector is correctly fitted to the board. If the DC input has switchable polarity, make sure the correct polarity is used. 
  2. Check the power supply is powered at the mains
  3. Check the electrical cable and plug fuse

No sdcard or incorrectly fitted sdcard

Check the sdcard is present and fully inserted.  You should hear a click when the sdcard is properly inserted into the slot.

SW2 switches are incorrectly configured

Check the following switch positions are in place to boot from sdcard:

  • SW2.1=OFF
  • SW2.2=OFF
  • SW2.3=ON

No sdcard image or corrupted image on sdcard

If you seeing kernel CRC checksum errors during boot-up or no console output whatsoever during boot-up, it is possible your sdcard image is not writing properly.  Some sdcard readers seem to have problems with writing very large image files, as needed by the image creation process.

It is possible to better diagnose such problems by using the sdcard-image-write and sdcard-image-verify tools that are provided in our http://support.icoteq.com:9000/Icoteq/icoteq-bsp-tools-env repository.  These tools use an MD5 check to confirm that the image contents written to an sdcard matches the file contents of the local filesystem.  Please consult the README file for more information.

If your problems persist, try using a different PC to write your sdcard image or purchase an external SD card reader such as the e-Blue Cadena+ (stocked by Maplin - http://www.maplin.co.uk/p/e-blue-cadena-56-in-1-card-readerwriter-a39hq) which we have tested.

Damaged sdcard

Try substituting the sdcard for a known good working sdcard.  Ensure the sdcard is written with a HDP-TTJ-500 sdcard image file before attempting to boot again.

Board DDR calibration out of specification

Run a DDR calibration test and compare the obtained DDR calibration values against the values that are used in u-boot for HDP-TTJ-500.

Check for console log failures

If all else fails, attach a USB serial cable to the serial connector J15.  Capture any output from the console output during the boot-up process.  You can obtain a more detailed output during the Linux boot-up process by modifying the u-boot bootargs setting and removing the quiet setting.

The console log should allow problems to be more easily diagnosed when reporting problems to Icoteq.

No Ethernet connectivity

Auto-negotiation failure

Ensure the ICO-TTJ-500 Ethernet port is connected into a switch or other port with 10/100 capability only.  Owing to a problem with link auto-negotiation, it is not possible to connect into a port advertising Gigabit capability.  This also precludes connecting two ICO-TTJ-500 boards back-to-back since the ICO-TTJ-500 PHY advertises Gigabit capability.

Demo GUI application does not start

If your board is booting into Linux normally, then the GUI application should start without any problems.  However, it is possible that the GUI application may fail to start if incorrect modifications have been made to gui.conf or the TransferJet kernel drivers fail to load.  Diagnosing start-up problems can be difficult so we suggest collecting log files and passing them on to us for further analysis.

It is also a good idea to check the software versions running on your system.  You can do this by following the instructions here.

Collecting log files

Check the following files from your target hardware:

  1. /tmp/pytjet.log
  2. /tmp/tjet-service.log
  3. Run dmesg > kernel.log to capture a kernel trace log

These files should allow problems to be more easily diagnosed when reporting problems to Icoteq.

Demo GUI indicates no connection established

The "Connected" indicator is depressed and highlighted red.

Antenna couplers are too far apart

Try reducing the distance between antenna couplers to see if this helps.  Ideally you should be able to see an RSSI value between 90 and 100 on both client and server.  The lower the RSSI value, the higher the signal strength.

Both boards configured as client or both as server

Ensure the "Mode" indicates "Obex Client" on one board and "Obex Server" on another board.  A connection will not be established unless opposing modes are configured.

SW2.4 defines the mode used by the software where ON=>Obex Client, OFF=>Obex Server.

Client or server daemon application has crashed

Try rebooting the client and/or server board by pressing SW5.

Demo GUI speedometer reads zero

Assuming the link is connected then this suggests that the daemon service application has stopped sending

Connection is dropped

Refer to the section on "Demo GUI indicates no connection established".

Performance test is not running

Press and quickly release SW4 and ensure that the "Performance" indicator is depressed and highlighted green.

Demo GUI speedometer does not reach peak throughput

It should be possible to reach approximately 240Mbps transfer speed from client to server.  If your speed is significantly lower than this, you can check the following.

Antenna couplers are too far apart

Try reducing the distance between antenna couplers to see if this helps.  Ideally you should be able to see an RSSI value between 90 and 100 on both client and server.  The lower the RSSI value, the higher the signal strength.

Antenna couplers' relative orientation is sub-optimal

Try adjusting the orientation of one of the couplers relative to the other and observe the effect on transfer speed.