26 May 2013 0:53:10
Latest News
First Time Visitor
Login
Register
There are 9 Guest users online.
Products
Emulation Tools
8xC51 Family
LPC76x Family
8xC51MX Family
LPC900 Family
Choosing an
Emulator
Programmers
Adapters
Bondouts/Spares
Repairs
Microcontroller Sales
Ordering
Show My Cart
Proceed to Checkout
Support
Downloads
Forums
Links and Resources
Data Sheets
Technical Notes
Testimonials
FAQ
Common Problems
Repairs and Returns
Contacting Us
About Acqura
Take our Poll
|
|
|
|
|
|
|
| Things not working the way they should? Maybe the solution can be found here - if not, please mail us at info@acqura.com. |
| | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Common Problems |
|
|
When I set the LPC76x reset ports low function the device still resets with the ports high. Is my emualtor faulty? |
|
This information pertains to the Philips PDS76x emulator.
When I set the reset ports low function the device still resets with the ports high. Is my emualtor faulty?
No - your emualtor is not faulty! The reset ports function is very closely tied into the function of the device - so much so that it has been decided to provide a special bondout for those cases where it is desired to reset the part into the port low condition.
Please contact us for additional information.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Common Problems |
|
|
I've upgraded my PDS51E software and now it says it can't load the USB driver. |
|
We have identified a problem that can occur when you update your PDS51E software and/or upgrade the version of Windows you are running.
Symptom
PDS51E reports it can't find a USB device, My Computer/Properties/Hardware/DeviceManager/Universal Serial Bus controllers/Acqura PDS51E Emulation System displays with a yellow exclamation mark and reports the driver could not be found or was not loaded correctly.
Cause
The wrong USB driver is being loaded, probably because an older copy remains on your PC, possibly one that Windows created during installation.
Resolution
Make sure you carry out all of the steps below. Windows sometimes makes "anonymous" copies of driver and INF files during installation of USB devices and these all need to be removed before the problem can be resolved.
- Close PDS51E and disconnect the emulator.
- Uninstall any versions of PDS51E you have on your machine. Uninstalling PDS51E will not disturb any of your project files or watch templates.
- Find and remove any files called PDS*.SYS, PDS*.INF (Click on Start/Find Files/Files Named PDS*.SYS;PDS*.INF). Make sure they are files related to PDS51E and not other files with a similar name. If you are in any doubt, rename the files instead of deleting them, e.g. add ".OLD" as an extension. The files related to PDS51E will probably be called PDS51E.SYS, PDSGEN.SYS, and PDS51E.INF or similar.
- Find and remove or rename any files matching OEM*.INF and containing the text "Acqura".
- Find and remove or rename any files matching *.INF and containing the text "Acqura" in their names.
- Restart your PC.
- Install the latest version of PDS51E click here to download).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Common Problems |
|
|
The PDS900 Programmer reports "Device is inserted backwards" |
|
You may receive this message even though you are certain you have correctly inserted your device to be programmed. If this is the case make sure the link on the PDS900 emulator board labelled Target Power is fitted. This link is located just below the connector for the emulation header/programmer board. The programmer circuirty derives its power supply from the emulator so this link must be in place for the programmer to work.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Common Problems |
|
|
I'm emulating the 80C51MB and my MOVX memory accesses aren't going off-chip. |
|
This apparent anomaly arises because an 80C51MC device is used to emulate all the devices in that family.
The 87C51MB device implements the external memory space data (XDATA - normally accessed by the MOVX instruction) as 768 bytes of on-chip data (AUXRAM) addressed at 0000 through 02FF, and 64768 bytes of off-chip data addressed at 0300 through FFFF.
If the 80C51MB device were accessing XDATA memory from addresses 02FE through 0301 the first two bytes would be read from internal AUXRAM and the last 2 off-chip.
The 87C51MC device implements 1792 bytes of AUXRAM on-chip (from 0000 to 06FF) and 63744 off chip (from 0700 to FFFF).
If the 80C51MC device were accessing XDATA memory from addresses 06FE through 0701 the first two bytes would be read from internal AUXRAM and the last 2 off-chip. If the 80C51MC device were accessing XDATA memory from addresses 02FE through 0301 all four bytes would come from the on-chip RAM.
The question that must be asked therefore, is what does the PDS51E emulation system do?
The answer is that the emulator will behave in the same way as the 80C51MC device. This is because the PDE51MX daughterboard uses the variant of the device which is a superset of all devices supported by the daughterboard. In this case, the 80C51MC device is used for emulation. This means that if your target code accesses XDATA memory in the address range 0300 to 06FF, it will in fact reference internal AUXRAM, and not off-chip memory.
You need to be aware of this behaviour if your target system will use the smaller device. The easiest way is to map any external devices above 06FF.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Common Problems |
|
|
I press F7 to step into a routine and the emulator behaves as if F8 (step over) had been pressed. |
|
This behaviour is observed whenever PDS51E cannot locate source stepping information for the destination routine. This will occur if:
- the destination routine is in a module for which there is no source line information available in the object file. You may be able to recompile or re-link the object module so that source line information is prodiced in the object file for the module concerned. Consult your compiler documentation.
- the destination routine has source line information available, but the source file itself could not be found. You need to make sure the source file is available. You may need to set the source search path appropriately.
- the compiler and/or linker you are using has optimised some common entry code and moved it to precede the routine being called.
As an example, say you have a routine that sends a character and the character is passed in ACC.
A C statement such as
send ("A") ;
might compile to:
mov a, #41h
call send
If the compiler finds more than one instance where you have called the routine with the same parameters, the optimisation stage may well decide to move the code the set up the parameters for that common calse to immediately in front of the routine itself, rather than duplicating the parameter code before each call. If this optimisation is carried out, the target routine then has two entry points, the standard one, and the one ahead of it where the most commonly used parameters are set up. The object file only contains a line number entry for the standard entry point so references to the second entry point are entry point cannot be stepped into, even if the source code for the routine exists.
The problem will normally go away if you reduce or turn off altogether the level of code optimisation performed by the compiler and/or linker.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Common Problems |
|
|
I was probing signals on my emulator and now it doesn't work |
|
You may have damaged the PLCC bondout socket.
We do not recommend probing any signals on the emulator PCB's themselves. If you need to monitor signals associated with the microcontroller such as port inputs and outputs, we recommend that you connect your probes to the jumper fields provided.
The bondout PLCC sockets are not designed for probing. Application of probes can irreversibly bend the spring contacts.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Common Problems |
|
|
Unreliable operation with PDS51 under Windows 98/2k/ XP when serial COM port expansion cards fitted |
|
Symptom
PDS51 runs sluggishly or reports serial errors when communicating with the emulator, or will only run successfully at 9600 baud. This problem is often reported when trying to run PDS51 off a serial port fitted to a plug-in serial expansion card.
Fix
You must have auto CTS/RTS flow control disabled for the port. To do this:
- Click on Start
- Click on Settings
- Click on Control Panel
- Open the System icon by double-clicking it.
- Open Device Manager (On Win2k, click on the Hardware tab, then click the Device Manager button).
- Expand Ports (COM & LPT) by clicking on the +
- right-click the port you are using with PDS51 and select Properties.
- click the Port Settings tab
- click the Advanced button
- make sure Enable Auto CTS/RTS Flow Control is not checked.
- click on OK to exit each of the dialogs.
IMPORTANT
This problem has only been reported with systems that have added extra COM ports via an expansion card. You may not see the option to enable/disable CTS/RTS flow control with other COM ports on your machine.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Common Problems |
|
|
Help! I can't get my assembly-language project started with Keil uVision and the LPC76x Emulator |
|
The following assumes you have installed both PDS51W (the emulation software for the PDS76x) and the Keil uVision2 software. It uses one of the example projects supplied with the Keil software, but should serve as a template for your own project:
- Start Keil uVision.
- Click on the "Project" Menu entry and then click on "New Project"
- in the "Create New Project" dialog that opens, navigate to the folder where you want to create your project. In this case, we suggest you navigate to C:\Keil\C51\Examples\ASM as that is where the example source files we will be using are located.
- enter a project name, such as "My First Project" and click on "Save"
- a dialog will open asking you to specify the target device. Choose "Philips" from the list and select "P87LPC764" from the device list. Click on OK.
- In the left-hand pane of Keil uVision, expand the "Target 1" item by clicking on the "+". You should then see "Source Group 1".
- if uVision 2 asks if you want to add a startup file, answer "no" as we don't need it in this assembly-language example.
- right-click Source group 1" and click "Add files to Source Group 1". Choose "All files" from "Files of Type", as the files we want to add do not have an ASM filetype.
- Add the files ASAMPLE1.A51, ASAMPLE2.A51 and ASAMPLE3.A51 by double clicking each in turn.
- Click on "Close" to close the Add Files to Group dialog.
- expand the "Source group 1" item to see the files you have added. If you double-click any of them they will be opened for editing.
- Click on the Target" item in the left-hand pane. Click on the "Project" menu entry and select "Options for Target 1".
- Click the "Output" tab. Where it says "Name of Executable", add the filetype ".OMF" to the name already there, so that the name of your executable is "My First Project.OMF". Keil does not add a filetype to executables by default, but PDS51W expects one.
- Make sure "Debug Information" and "Browse Information" are checked. If you want a hex file (e.g. for a programmer) make sure this is checked also.
- click on "OK" to close the projects options dialog.
- at this point you need to edit each of the three files. At the start of each file is a "Name" directive, e.g. the file ASAMPLE1.A51 has the line
NAME SAMPLE
as the first line. Comment out these lines in each of the three source files by placing a semicolon as the first character of these lines. PDS51W requires the name of a module to match the name of the source file.
- build your project by pressing the F7 key. The linker will report an address space overflow, because the example source file declares an otherwise unused 64 byte memory area which exceeds the P87LPC764's memnory capacity. Open the file ASAMPLE3.A51 and find the line that reads:
DUMMY: DS 40H
and change it to read :
DUMMY: DS 10H
- build your project with F7 again. It should report no errors this time.
That concludes the Keil uVision setup. Now for PDS51W.
- open PDS51W.
- click on "File", then "New Project"
- click on "File", "Save Project As" and choose the same folder as before and the name "My First Project" or whatever for your PDS51 project name. This will create a file "My First Project.PDS" which will remember all your settings.
- click on "Options", "Object File" and select "Keil C" as the Source Origin. Note that you should use this option even if your project uses assembly-language source files.
- Click on "Properties" and change the contents of the "Source Filetypes" field to read "C;A51". This instructs PDS51W to look for source files that end in .C or .A51.
- Click on "OK" to close the "Properties" dialog
- Click on "Browse" and choose the file "My First Project.OMF" from the folder C:\Keil\C51\Examples\ASM
- Click on "OK" to close the "Options" dialog. The object file should load.
- Click on "Pane", then "New Pane", then "Code"
- Right-click in the Code pane and select "Source" instead of "Disassembly". You should see the source files displayed.
You should now be able to step through this project with the F7 and F8 keys.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Common Problems |
|
|
I can't get source-level debugging working with the Keil Compiler |
|
This note describes the steps involved in getting source-level debugging working when using Keil uVision 2.
- If you are using PDS51E/PDE51MX, and generating code for a 87C51MX family device the Keil compiler will be generating extended OMF records. The source origin for your project within PDS51E (click on Options/Object File/Source Origin) must be set to Keil C (Extended OMF).
- If you are using PDS51 the Keil compiler will be generating standard OMF records. The source origin for your project within PDS51E (click on Options/Object File/Source Origin) must be set to Keil C (Standard OMF).
- By default, object files created by Keil uVision have no extension. You should change this so that the object file has an extension such as .OMF. This will prevent ambiguity as to which is a source file and which is the object file.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Common Problems |
|
|
PDS900 reports "Error reading Product IDs" or "PDS51E was unable to read the bondout identification information from the emulator" on startup. |
|
In order to correctly select the logic and firmware to load, PDS51E needs to identify the emulation bondout fitted. If the information read back does not represent a known device an error "PDS51E was unable to read the bondout identification information from the emulator" is reported.
Note
Some earlier revisions of the PDS900 emulator did not reset properly under some conditions, particularly when there is little or no additional load on the power supply, and may return this error. The emulator should reconfigure itself properly if you press the blue Restart button.
Current production emulators are fitted with a small resistor to provide this additional current load which should ensure a clean start to the bondout. The fitting of this resistor can be verified by measuring from the top pin of the target power jumper group and ground, which should measure less than 1k Ohm. If the reading is above this value then fit a 1k Ohm resistor between these measurement points. This quite easily fitted on the underside of the board (be careful removing the PCB from the half-case - a wide steel ruler is helpful with extraction and refitting).
If this problem persists, even after verifying or implementing the above modification, please contact us for assistance at support@acqura.com.
Please note that an earlier version of this 'Common Problem' report incorrectly stated the resistor value as 4k7 - the correct value is 1k as stated above.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Common Problems |
|
|
My project has relay-switched loads. When the relays switch my emulator stops responding. |
|
Some customers have found that PDS900 stops responding when their application switches relays or other inductive loads on or off. This can occur when induced noise spikes cause the emulator control processor or the USB system to malfunction.
The most common symptom is that your application target will continue to execute but the emulator will not respond to commands from the PDS51E control software. The status bar at the bottom of the PDS51E window shows "Communication lost". You can normally recover by pressing the blue reset button on the emulator.
There are several things you can do to help eliminate this problem. Bear in mind that noise spikes of sufficient magnitude to disable the emulator may also be troublesome when your target code is running outside of the emulators control, I.e. after you have programmed your micrcontroller and soldered it to the board, so any steps you can take can improvel help the reliability of your product as well.
- make sure any inductive loads (such as a relay coil) switched with a transistor have a back-EMF diode across the transistor.
- any relay contacts that switch inductive loads such as motors should be fitted with resistor-capacitor "'snubber" networks.
- pay careful attention to grounding on your PCB.
- ensure there can be no earth differential between your target and the PC that is connected to the emulator. This is best achieved with a connecting wire between mains earth on the target hardware and the chassis of your PC.
 IMPORTANT. Always proceed with caution when making electrical connections to mains-powered circuitry. Incorrect wiring can damage your target application, the emulator or your computer system, as well as placing you in danger of electric shock. The above should only be carried out by personnel qualified to carry out mains wiring. Never work on mains wiring alone.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Common Problems |
|
|
When trying to set the comparator input value on P0.5 in the LCP76x emulator there appears to be a current being sourced from the emulator even though I have set the pin to HiZ. Where is this current coming from? |
|
This information pertains to the Philips PDS76x emulator.
When trying to set the comparator input value on P0.5 there appears to be a current being sourced from the emulator even though I have set the pin to Hi-Z. Where is this current coming from?
All pins on the 87LPC76x family are multi function and many of them can also be traced along with the execution flow.
Generally the aditional current could be comming from the device itself, or the supporting hardware of the emulator.
The first item to verify is that the device is not supplying the additional current. Therefore ensure that the relevant pins have been configured to Hi-Z in software (PxM1/2 registers define which of the four possible modes a port pin may take). Also verify that the PT0AD register is correctly set.
The second possible source is the emulator hardware. If the affected pins are P0.5 (CMPREF), P0.6 (CMP1) or P0.4 (CIN1A) then ensure that the associated input is not linked to be traced. These inputs are weakly pulled high (47k ohm) and will therefore source a small amount of current. The trace system is designed to trace digital inputs and should be disconnected from an analogue system.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Common Problems |
|
|
With the PDS76x emulator IDE I cannot see the code area 0FCE0h to 0FCFFh. Why is this? |
|
This information pertains to the Philips PDS76x emulator.
With the IDE I cannot see the code area 0FCE0h to 0FCFFh. Why is this?
This area of the devices memory range is not actually available to the user for executable code. Therefore the IDE does not allow it to be displayed.
However the device has the ability to address up to 16K bytes of code memory although current varients have less -
- P87LPC762 2K
- P87LPC764 4K
- P87LPC767 4K
- P87LPC768 4K
- P87LPC769 4K
The emulator already contains memory to the 16K limit and therefore allows user programs to be this large. This additional memory (between the device limit and the emulator capability) could be used, prudently, for additional debug routines. If you use this approach remember to remove the routines, and the calls to them, before programming a device!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Common Problems |
|
|
I wish to store data within the Customer Configuration Space (CCS -
FCE0h through to FCFFh), however when I try to access it with a MOVC
instruction I get an 0FFh value. Why is this and can it be worked
around? |
|
This information pertains to the Philips PDS76x emulator.
I wish to store data within the Customer Configuration Space (CCS - FCE0h through to FCFFh), however when I try to access it with a MOVC instruction I get an 0FFh value. Why is this and can it be worked around?
When the device is functioning as a bondout all user accesses above the 16K byte boundary is inhibited (and typically return an FFh value). The exception to this rule is the UCFG1 register (at FD00h) which must always be accessible to configure the device correctly.
Therefore, when emulating, the user cannot access the CCS memory area in the intended way (and so the IDE does not provide any method to initialise or display it).
The work-around is to temporarily recreate the CCS as an image somewhere within the program code memory while emulating. As the emulator provides code space up to 16K bytes the obvious choice is somewhere above the natural device limit.
The easiest way to provide such a change is to have some conditional assembly (compilation) that switches the equate between the proper location and the relocated image. Ensure that prior to production release of the code that the equate is correctly set!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
If you see this message in the status bar of PDS51E when you start up (and your emulator was previously working) you may have corrupted data in the configuration EEROM. Luckily, this is easy to fix.
- Start PDS51E and look for the help topic "Procedure for manually updating PDS51E Boot Code". This gives step-by-step instructions for the process, including photographs of the board clearly showing which links to fit.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Common Problems |
|
|
I get "Not a Philips Device" when I try to program a P89LPC901/2/3 |
|
We have identified this as a problem with PDS900. If you open the programmer and select any device that uses ICP (such as the P89LPC901 device) rather than parallel programming, you will receive an error message "Not a Philips Device" when you attempt to program the part if the selected device when you started the programmer was a part that is parallel programmed, such as the P89LPC932. If you have been using the emulator to program parallel-programmed parts and you then try to program an ICO-programmed part you will most likely see this error therefore.
The problem will be fixed in an upcoming software release, but the work-around in the interim is as follows:
- Start PDS51E.
- Start the Programmer.
- Click on the Device tab.
- Select the device you intend to program.
- Click on the OK button to close the programmer.
- Open the programmer again.
- Check that the correct device is selected.
- You should now be able to successfully program the device.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Common Problems |
|
|
Why can't I get P1.2 into quasi I/O or push-pull output mode? |
|
This note applies to the PDS900 emulation system.
PDS900 uses a P89LPC935 bondout device to emulate all members of the LPC900 family. As the P89LPC935 device has an I2C interface, the pins that interface with the I2C subsystem (P1.2 and P1.3) are necessarily open-drain outputs. They cannot be configured as quasi I/O or push-pull mode outputs as the requisite hardware does not exist on those port pins on a P89LPC935.
This presents some limitations when you are emulating devices that implement P1.2 but do not have an I2C interface (currently only the P89LPC901, P89LPC907, P89LPC912 and P89LPC914 devices). These devices are capable of operating P1.2 in quasi I/O or push-pull mode, but PDS900 will ignore any attempts to program P1.2 into these modes as the P89LPC935 bondout does not support it.
This limitation would also apply to any device that implements P1.3 and does not have an I2C interface, however there are currently no such devices in the P89LPC900 family.
Note that this is an inherent limitation of the Philips bondout devices and there is no work-around. All emulators for the P89LPC900 family (regardless of vendor) suffer from this limitation.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Common Problems |
|
|
I get "Not a Philips Device" when I use the PDS900 programmer |
|
This note pertains to the PDS900 emulation and programming system.
Symptom
When you exit the programmer, PDS51E reloads the object file you were using for emulation and reconfigures the voltage, clock speed etc for the current project. If you start the programmer up again before this re-initialization has completed, the programming interface can fail to initialize properly. This situation can also occur if you start the programmer immediately after starting PDS51E, before the emulator has a chance to fully initialize.
Work-around
Wait until the emulator has finished initializing (I.e. finished loading the object file and scanning any source files) before starting the programmer.
Resolution
We have confirmed this to be a problem with software versions 4.46 and prior. Subsequent versions will fix the behaviour.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Common Problems |
|
|
I can't get source-level debugging working with the Raisonance compiler |
|
The following steps should get you started when using the Raisonance RIDE integrated development environment with PDS51E or PDS900:
- Start RIDE
- Create a new project by clicking on Project/New
- Assign a name to your project. This will create a file called [name].prj. It is best to create the project file in the same folder as the source files for your project.
- Add source files to your project by Clicking on Project/Add node Source/Application
- Compile and link your project by clicking on Project/Build All. This will create [name].AOF.
- Load [name].aof with PDS51E.
If you are using the Raisonance tools from the command line, remember to specify the DEBUG option to include debugging information when you assemble. So if you were assembling a file test.a51:
- c:\ride\bin\ma51 test.a51 debug
is the command line you would enter (assuming you have installed the tools in the default folder).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Your session has probably expired. If you have cookies disabled on your computer, you won't be able to place an order because we use cookes to store your session information. We don't store any other information and no information other than that which you type in is ever sent from your browser to us.
Your session will also expire if you don't request a page from the site within a certain time. If you find your cart is suddenly empty, just use the 'Back' button on your browser to show the products you were trying to order again.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Common Problems |
|
|
I get 'HELP/NAVIGATION ERROR - Server Error The server failed to return this URL' when I try to order. |
|
Some customers have reported this error from their browser when they try to place an order:
HELP/NAVIGATION ERROR - Server Error
The server failed to return this URL
This is generally caused by "spyware" software installed on your PC interfering with the browser operation.
This problem can also occur if If you have "Internet Optimizer" installed.
We recommend downloading and installing Ad-Aware from Lavasoft (http://www.lavasoftusa.com). This will cleanse your PC of spyware products.
|
|
|
|
|
|
|
|
|
|
|
|