1.
|
You should start by running any utilities provided by your DSP vendor to check that the hardware and associated device drivers have been installed correctly and are functioning.
|
2.
|
Can you run the example-1 (hello world) from the Diamond examples folder? If you can, the problem lies in your application. If you can’t, there is likely to be some problem with your DSP hardware. Check the following points for further suggestions:
|
3.
|
Have you changed the server’s Standard I/O options? Redirecting all output to a file rather than the screen can make an application appear not to run, for example. If in doubt, reset the options to the safe default state by selecting View/Options and pressing Reset to Default Options.
|
4.
|
Does your hardware appear to be working? Many DSP boards have indicators (LEDs) that display some processor state. Check with your board documentation that these are showing the expected state.
|
5.
|
Is the board’s power supply correct? Some DSP modules need to be screwed down to a carrier board to receive correct power.
|
6.
|
Does your application load? You can check this from the server by ticking View/Options/Monitoring/General Monitoring and trying to run your application. You should see three monitoring messages:
|
MON: Resetting DSP modules
|
|
MON: Loading your application
|
|
MON: Loading completed
|
If these messages do not all appear, check the following:
|
| • | Has your application been built properly? |
|
|
| • | Have you used the Diamond 3L command or did you call the TI tools directly? Tasks built using the recipes in TI’s manuals not work under Diamond. |
|
|
| • | Did you build your application for the correct processors? Applications compiled for the 62xx processors (3L C, 3L T) also work on both C62xx and C67xx processors. Applications built for c67xx processors (3L C67, 3L T67) will not execute on c62xx processors. |
|
|
| • | Were there any error messages from the configurer when you built the .app file? You should correct any problems here first. |
|
|
| • | Do the processor types in your configuration file match the processors in your system? Is your DSP network connected properly? |
|
|
| • | Does the number of processors in your hardware system correspond to the number of PROCESSOR statements in the configuration file used to build the application? |
|
|
| • | Are the processors connected in the way described by the WIRE statements in your configuration file? External cables, pre-defined links, or programmable links can connect processors. Check that all necessary connections have been made correctly. |
|
|
| • | Some PC boards have a distinction between a 'root' board, which has a link to the PC, and 'non-root' boards, which have no such connection. Check that any necessary switches on the boards are set in the appropriate ways. Also, note that some boards give you access to the link used to communicate with the host. Make sure that you have not connected this link on the root processor’s board to any other link. |
|
|
| • | Can the server see all the boards you expect? Check using Board/Select. |
|
|
| • | If you have more than one DSP board in your system, have you selected the correct one? The server shows the selected board at the bottom right of its window. |
|
|
7.
|
Have you given enough memory to your tasks? Check the TASK statements in your configuration file.
|
8.
|
Have you used the appropriate #include files in your source programs? A common mistake is to forget to include stdio.h. Also, check that you are getting the Diamond include files and not TI’s.
|
9.
|
Is some other application using the same DSP system? This could be another instance of the server or a board maintenance application from your board vendor. Under certain rare circumstances, it is possible to kill the server’s user interface without shutting down the server properly. Stop the server and check using the Task Manager (Processes) that there aren’t any instances of WS3L.exe running. You can safely stop any you find (End Process).
|
10.
|
Have you been using Code Composer and left any of the DSP processors halted? If you have been using Code Composer, start it again, and for each processor: halt it if necessary, and then select 'Run Free'. Try running your application again.
|
11.
|
Check that your application is starting to run by putting a printf at the start of main in one of the tasks on the root processor. If this generates output, the problem lies further on in your code. Some common errors are:
|
| • | Using semaphores before they have been initialised with sema_init. Note that you must not initialise the semaphore par_sema. |
|
|
| • | Using events before they have been initialised with event_reset. |
|
|
| • | Using a local channel before it has been initialised with chan_init. Note that you must not initialise the channels passed in as parameters to main. |
|
|
| • | Forgetting to use the appropriate header files, notably stdio.h , and thread.h. |
|
|