19 May 2013 4:00:13
Latest News
First Time Visitor
Login
Register
There are 8 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
|
|
|
|
|
|
|
| Any questions about us? Hopefully anything you need to know about us is answered below - if not, please mail as at info@acqura.com. |
| | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FAQ |
|
|
Inadvertent LPC9xx Flash memory overwrite |
|
When power cycling the LPC932 the VDD has to drop below 0.2V to ensure that the part will correctly reset. If the power does not drop below the 0.2V then there is a chance that the chip will not get a correct reset and all the SFR can be in an undefined state.
When this happens the program counter can be corrupt and there is a chance that the part will jump/run into ISP or IAP code with a risk of performing a Flash operation such as an erase or program byte.
To solve this Philips have developed a new ISP code and IAP code. The new ISP/IAP code will require a key to be passed to the IAP code, and if the key is incorrect the IAP function will be aborted.
All newer devices such as the LPC931 have the new ISP, however the current LPC932 does not have the new ISP/IAP. A special part number has been created to allow the LPC932 with the updated ISP/IAP to be ordered (the part numbers would have the extension CP3235 - for example P89LPC932FDH/CP3235).
Philips are currently working on providing an LPC932/01 that will have the updated IAP/ISP and the option to carry out byte-erasable Flash.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FAQ |
|
|
My emulator needs repairing |
|
Emulators are a little different to the usual electronic devices in that they are frequently connected up to circuitry of unknown parentage, or systems still under development. As a result, there are bound to be occasions where the emulator is subjected to electrical stress, whether it be due to an incorrectly adjusted bench power supply or a slip of the 'scope probe.
Acqura emulators are designed to be as rugged as is possible without sacrificing the transparency of the emulation provided, but there will be occasions where the smoke escapes!
If you suspect your emulator is damaged, there are some quick and simple tests you can perform to confirm and possibly localise the damaged part. Click here for information on these tests and the steps you need to take before returning goods to us.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FAQ |
|
|
What does 'No stolen resources' actually mean? |
|
"No stolen resources" refers to the level of intrusion the emulator makes into your target system.
Emulation should be as transparent as possible, meaning it should not:
- use any of the user's code space.
- use any of the user's stack space
- use any other data storage
- require any additional clock cycles during execution
- make any of the port bits unavailable.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FAQ |
|
|
Does my emulator come with a warranty? |
|
Yes, all Acqura products come with a warranty, which covers faulty components or manufacturing defects.
Our warranty statement...
"Our emulation systems are guarenteed for a period of 12 months from the date of sale and will be repaired or replaced at our discretion as appropriate. The guarantee does not cover damage due to excess voltage or currents (or other abuse) as detailed under General Precautions and will not apply to units which are physically damaged or modified in any way."
To explain further...
The 'General Precautions' simply covers the application and removal of power to the emulator/target combination and advises against the application of voltages beyond the supply rating of the bondout or system.
In our experience, gained from the very large number of units that are in the field, there have been a minimal number of failures due to manufacturing errors. These we have repaired at no cost, and probably would do so beyond the nominal 12 month warranty period.
The typical repair flow is…
A customer will contact us and state that an emulator or programmer has failed. During the dialogue that follows they will be assisted in determining the faulty components and they then purchase these to repair their product. This usually results in the product being returned to a functional state in the absolute minimum of time. Of course the unit can be returned for repair if the customer wishes or if it is determined that the damage is too extensive to be diagnosed over the web. In support of this we carry stock of emulation bondouts, port regeneration, and other devices.
With the PDS51 emulator most repairs simply require the replacement of the bondout or one (or more) of the port regeneration devices. With PDS76x there is no port regeneration and a bondout replacement is usually all that is required. The new generation PDS51E and PDS900 emulators are a little more robust in design but do present more of a repair challenge due to the extensive use of surface mount technologies.
For products which are damaged by the customer and fall outside the warranty provisions we charge a (discretionary) US$25.00 to look at it and then charge per device replaced, plus shipping costs as appropriate. Customers generally have the option of having replacement devices or products shipped by surface mail at minimum cost or via international courier for maximum speed. It is important to remember that we cannot falsify shipment value so a full emulator may attract duty as it progresses through customs.
A cautionary note…
Due to the nature of the bondout an emulator is typically only as robust, and as fragile, as a real microcontroller device. We have had cases where customers have applied excessive voltages (12 to 600V with high energy available) which has caused extensive damage to the product. Of course this sort of damage is far beyond what can be covered by any warranty.
Hopefully this will have provided you with details of our warranty, but also with details of how we approach the general issue of servicing our products that are distributed widely throughout the world. If you have any other questions or concerns please feel free to raise them with us.
If your emulator is needing to be returned please ensure that your read the Returns and Repairs notes before sending your emulator back. We require all emulation systems to be adequately packaged for return.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FAQ |
|
|
When I press F9 (Run) the emulator only executes one instruction and then stops. |
|
Check your Code Limit setting (click on Options/Object File).
If the code limit is set to a value less than the current execution address, emulation will break after one instruction.
Note that if you have Auto Set checked then the code limit address is automatically set to one higher than the last code address loaded whenever an object file is loaded.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FAQ |
|
|
Restoring ISP in LPC9xx devices |
|
The larger members of the LPC9xx family contain In System Programming (ISP) code located in the last 512 byte block of the code memory area (the actual location varies depending on the memory size of the family varient). The ISP code allows the device to be programmed via the onboard UART through a simple serial protocol.
During programming it is potentially possible, through the mis-application of the global or page erase commands, to remove this ISP code. The immediate programmer operation will fail as the executing code has been erased. This will also leave the device in a state where it can no longer be programmed by an ISP programmer.
So, is it possible to restore a device that has had the ISP code erased?
Yes, it is possible but requires either a parallel or ICP programmer, and an image of the corrent ISP code for that varient.
There are a number of ICP or parallel programmers available for the LPC9xx family. However, if you have a PDS900 then you already have a parallel or ICP programmer. Whether you need an adaptor or an interface to your target will depend upon your particular circumstances.
Philips have provided public copies of the ISP code that can be downloaded from their website. They have also provided an applications note that describes how to include the ISP code in your project, although you may opt to generate a dummy project that consists of only the ISP code. Once again, the approach you take will depend on your circumstances.
The applications note can be found at:
http://www.semiconductors.philips.com/acrobat_download/applicationnotes/AN10337_1.pdf
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FAQ |
|
|
What exactly is an emulator anyway? |
|
We are often asked what constitutes an emulator, and how a full emulator differs from a monitor-based system, or a "ROM emulator".
The Philips emulators sold by Acqura are "full" emulators, in that they are designed to replace the microcontroller during the development phase of a project and "emulate" that microcontroller with no or minimal affect. You can load code, execute at full speed, step instruction-by-instruction, break execution at a particular address, trace previous instructions, watch registers and variables, etc. Once your code has been developed using the emulator, the same code can then be programmed into a device and should behave identically.
A monitor-based system is usually cheaper and provides similar functionality but with some important restrictions:
- some microcontroller resources are "stolen" to support the monitor operation. These can include any or all of stack space, internal memory, code space, or execution cycles.
- usually, it isn't possible to regain control of an errant execution path, e.g. a jump into an area where there is no valid code.
A "ROM Emulator" is not a true emulator at all, but a hardware system where your ROM is replaced by RAM. These are only appropriate where the code resides in external ROM, rather than in on-chip ROM. Their functionality is generally very limited.
If you write code that works first time then you don't need any development system at all, and we are very pleased for you. For the rest of us however, the advantages of a full emulator become most apparent when those harder-to-find bugs start to surface. If you have a system that runs fine most of the time but crashes once per day, features such as break on execution outside the object file address range and a deep trace buffer are going to be powerful tools. You don't have to save too many development engineer-days before an emulation system pays for itself.
An article worth reading is one by Jack Ganssle on the real costs of development tools. Click here to open this article in a separate browser window.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FAQ |
|
|
Why does the TSSOP28 adapter for the PDS900 emulator have 30 pins? |
|
The TSSOP28 adapter for the PDS900 emulator is actually fitted with 30 pins. This is because the connector is a 30-way connector.
When fitting the adapter, make sure it is positioned as shown in the diagram:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FAQ |
|
|
When I single step my PDS900 it suddenly jumps to address 1E00h |
|
Check that you don’t have the P89LPC93x UART configured for break detection. If break detection is enabled on the UART and the break condition is present on the receive input, the processor will vector to the ISP entry point (typically) 1E00h.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FAQ |
|
|
Defining UCFG1 in the LPC9xx family |
|
The operation of a LPC9xx device is defined by the UCFG1 register. Amongst other things this register defines the clock source, reset pin operation, brownout enable, etc, and therefore has to be correctly set to ensure that the program operates with the intended hardware features enabled.
You can initialise the UCFG1 register in the '921 by assigning it a value where the address is FF00h. Due to the tightly coupled nature between the UCFG1 register and code operation is very wise to define it in your code (this helps to ensure that what is debugged and what is programmed into a device is always the same).
Extracted from the PDS900 help is the following text:
The PDS900 emulator provides the ability to specify the User Configuration bytes UCFG1 and UCFG2 and the boot vector status and value bytes in the object file. By agreement between Philips and third-party tool providers, this addressing is as follows:
| Address | Use |
| FFF0h | UCFG1 byte |
| FFF1h | UCFG2 byte (ignored – internal use only) |
| FFF2h | Boot vector value byte |
| FFF3h | Boot vector status byte |
| FFF4h | Security bits for sector 0 |
| FFF5h | Security bits for sector 1 |
| FFF6h | Security bits for sector 2 |
| FFF7h | Security bits for sector 3 |
| FFF8h | Security bits for sector 4 |
| FFF9h | Security bits for sector 5 |
| FFFAh | Security bits for sector 6 |
| FFFBh | Security bits for sector 7 |
These locations apply for ALL variants in the LPC9xx family. The PDS900 programmer will pick up all bytes assigned to these locations and correctly drop them into the appropriate registers when programming a part.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FAQ |
|
|
A Cautionary Note - The LPC932 family I/O ports reset to input only mode |
|
The new LCP9xx family of microcontrollers from Philips are advanced 8xC51 derivatives. One of the advanced features is that the port pins reset to input only mode whereas more traditional 8xC51 a quasi-bidirectional at reset. This can be a serious 'gotcha' if this is overlooked as the resulting floating input can cause strange behaviour (for example a floating RXD pin may cause the device to go into the ISP programming mode).
So, why the change? With the traditional 8xC51 devices the port pins will be high from reset until the control firmware takes over and writes safe values to the ports (this would be a problem if the high level during reset enabled external power circuitry). With the LPC9xx family ports taking the input-only mode at reset it is now possible to use pull-up or pull-down resistors to take the pins to safe values directly. Once the firmware has control the desired port mode and levels can be set (of course set the output latch value before changing the associated mode).
When pins are unused in a design, we recommend setting to quasi-bidirectional mode and then set high to minimise the current drawn.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FAQ |
|
|
I can't see structures and arrays in the watch window |
|
Symptom
I'm using the command-line versions of the Keil tools (C51.EXE, etc) from a batch file. My project compiles and links OK but all my variables display as "untyped" in the watch pane.
Solution
Make sure that you have the command-line options BROWSE DEBUG OBJECTEXTEND specified when you invoke the compiler.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FAQ |
|
|
Why do Acqura's emulation systems cost so much less than the competition? |
|
Our emulation systems are low-cost because:
- most of our sales are internet-based
- we manufacture in New Zealand, which enjoys a competitive exchange rate against other world curencies.
- We aim to provide outstanding value for money - one of our customers has purchased over 30 emulation systems! See how our PDS900 compares with other vendors products here.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FAQ |
|
|
PDE51Mx - 24/16-bit memory mode problem |
|
Philips have recently released updated varients of the 87C51Mx2 devices. The most important enhancement is the introduction of a mixed 24/16-bit memory mode. This has required two additional control bits in MXCON (ECRM and EAM1 - the original EAM bit is now referred to as EAM0). Readers are recommended to download and read the latest user manual for the 51Mx2 family of devices.
The mixed memory mode is configured by EAM[1:0] = 10 and allows for the MX memory organisation internally (access to the full internal code memory of >64K), but with the standard 8xC51 16-bit external interface. When combined with ECRM = 1 the CALL/RET instructions work on 24-bit address data. This allows compilers to generate more compact code by only using CALL and RET instructions while allowing program size to migrate passed the 64K boundary.
These additional control bits are not implimented with the old bondouts (labeled R1.1 or R1.2). With the mixed memory mode selected and extended call/return enabled, a 24-bit addess is pushed on the stack by ECALL but only a 16-bit address is popped by a RET (resulting in the program executing from the wrong return address).
The solution is to upgrade your emulator bondout which are available from www.acqura.com
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FAQ |
|
|
PDS900's Good running |
|
Now I'm happy by the PDS900's Good running.
The PDS900 will be very useful in my project.
I think your product is best in 8051 emulator.
Anyway Thanks for your help.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FAQ |
|
|
I am using PDS76x to emulate the 760 device but notice that the RC oscillator is out or tolerance |
|
The original members of the LPC76x family (the LPC769 and LPC768) had quite a wide tolerance (+/-25%) RC oscillator. The oscillator tolerance has been improved as the devices have been refined and additional members introduced into the family. Currently there are devices available with basic oscillator tolerances of +/-2.5%, +/-10%, and +/-25%.
The LPC764 and LPC762 were the first to be improved and they were released with a +/-10% oscillator.
The LPC760 and LPC761 followed and were released with a +/-2.5% oscillator across 0C to 50C so that serial communication is possible with this device. The LPC764 has also been released with this oscillator.
Those devices with a +/-2.5% tolerance are actually calibrated at Vdd = 5.0V and room temperature to be within +/-1%.
The bondouts provided by Philips have the original +/-25% RC oscillator and Philips have indicated that there are no plans to apply the new tighter tolerance RC oscillator to the bondouts. Also as far as we are aware there is no way to trim the oscillator programatically or electrically.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FAQ |
|
|
What is the correct use of the Int/Ext power jumper provided in the PDS76x emulator? |
|
The Int/Ext jumper simply changes where the bondout is powered from. The remainder of the emulator is still powered by the supplied PSU (termed a wallwart or plugpack) and therefore the main emulator supply MUST be present at all times for correct operation of the emulator.
With the jumper in the 'Ext' position customers to sweep the supply through a range of voltages (for example as if they had a slowly decaying battery) or if they want a supply voltage other than 3.3V or 5V. With the jumper in the 'Int' position then the supply voltage can be selected from an internally sourced 3.3V or 5V.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FAQ |
|
|
Is there a Beta release of PDS51E available? |
|
You can download a beta release of PDS51E at:
http://www.acqura.com/downloads/pds51e/beta/pds51ebeta.zip
The release of PDS51E downloaded from the above link will generally be 'ahead' of the regular download. It is still a full installation package and will include details of the improvements up to that version in the file README.TXT that is installed. Note that:
- No guarantees are offered for the stability of beta releases. In some cases they are released at short notice with minmal testing to help specific customer problems.
- A feature included in a beta release is not guaranteed to be present in future releases.
- The same level of support cannot necessarily be expected for a beta release.
- you should back up your project files and template files before installing any release of PDS51E.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FAQ |
|
|
I monitor SFR values in the Watch pane but notice that at times the value written is not the value read. Why does this occur? |
|
This can occur for two reasons - both depend upon the SFR and also the device features so the following comments are general in nature.
1) Some SFR registers consist of separate read and write registers. The UART data SFR is a good example of this where the write targets the transmit buffer while reads access the receive buffer. The IDE is aware of such functionality and indicates in the SFR name the access limitations (for the above example the LPC932 devices has SBUFrd (read-only) and SBUFwr (write-only)).
2) Another display confusion occurs with control registers where all the bits are not implemented. There are many examples of this but the IEN1 register of the 89C669 demonstrates the display irregularity that occurs.
This IEN1 register has the following bits:
- - - EI2C - ES1T ES0T ES1R
The datasheet states the following: 'The unimplemented bits (labeled '-') in the SFRs are 'X's (unknowns) at all times. '1's should NOT be written to these bits as they may be used for other purposes in furture derivatives. The reset values shown for these bits are '0's although they are unknown when read'.
The majority of times these bits read back high so writing a 01h value will be read back as 0E9h. The IDE does not mask the unused bits in such registers so it reflects exactly what would be read by the executing program.
The most important thing to remember is to NEVER write '1' values to the bits that are not implimented in the varient you are targeting.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FAQ |
|
|
LPC9xx Family Clock Rates |
|
The LPC9xx microcontroller family from Philips has very quickly achieved wide acceptance since it's introduction.
The original member was the P89LPC932 which was specified to a maximum of 12MHz operation across the specified supply voltage range of 2.4V to 3.6V.
However, the family has been progressively expanded and now boasts in excess of 25 members, all with a variety of features and functions. It is interesting to note that all these newer devices (including the P89LPC932A1) have had a change to the basic specification: the operating clock range has been extended.
The clock specification is now split into two portions, which has caused some confusion mongst users.
AC Characteristics 2.40V to 3.60V lists the maximum external clock rate as 12MHz.
AC Characteristics 3.00V to 3.60V lists the maximum external clock rate as 18MHz.
It is important to realise that to operate above 12MHz requires a supply voltage above 3.00V.
Our PDS900 emulator features both a programmable voltage supply and a programmable clock making it easy for a user to operate the system in the upper clock rate region of the device operating curve. It is interesting to note that in our tests PDS900 was completely functional beyond the specified upper clock rate of 18MHz which indicates that it should provide stable and reliable operation at the 18MHz limit.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FAQ |
|
|
What adaptors do I get with the PDS900 emulator? What other adaptors are available? |
|
We make a large range of programming and emulation adaptors for the PDS900. Some of these are included with the PDS900 emulator, and some are available as an additional purchase. We also have "consumables" available such as small footprint solder-downs. To see what is available for each of the LPC900 family devices click here.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FAQ |
|
|
Why do I need an emulator with these new flash-based parts? |
|
Many developers think that the advent of flash-based microcontrollers such as the P89LPC932 removes the need for an emulator.
Nothing could be further from the truth. The only thing that flash micros give you is the ability to reuse your chips. They don't make code easier to write or bugs easier to find.
Consider this scenario:
- your code runs fine most of the time but occasionally seems to behave as if a crucial variable is being altered when it shouldn't be.
Now consider your options:
- stare intently at the chip on the board.
- read through your code listings line-by-line in the hope of spotting something.
- add copious amounts of debug code to output internal states to port pins or send them out the serial port.
Or…
- use the power of an emulator to find your bug.
With emulation support, you can chase bugs aggressively. For example, in the above scenario, is the code jumping back and somehow executing the initialisation code again? This is easy to check - just put a breakpoint in the initialisation code. If execution ever breaks there at any time other than startup, you can look in the trace buffer and find out how the execution path ended up there.
Because it only takes seconds to edit cour code, compile or assemble it, and load the new object code into the emulator, you can quickly try code modifications. In the above scenario, you can add a small fragment of code to check the variable's value and jump to a statement with a breakpoint on it if it ever gets assigned an incorrect value. Once again, inspection of the trace buffer should then quickly tell you where it was assigned.
Emulation systems quickly pay for themselves through faster turn-around times (a matter of seconds between code modifications and having the modified code running in your target instead of minutes) and through greatly reduced times taken to find bugs.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FAQ |
|
|
Why should I buy an emulation system from Acqura Systems? |
|
Acqura Systems have been providing quality emulation and programming support for Philips microcontrollers for ten years.
We target our tools to Philips micrcontrollers and enjoy a close working relationship with the Philips design laboratories in Eindhoevn, Hamburg, Sunnyvale and Taiwan. As well as our existing product range, we have provided several custom emulation solutions for Philips targeting special variants of the 80C51 family.
Because Acqura has no affiliation with any software vendor, we strive to provide support for all the major compiler manufacturers.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FAQ |
|
|
My IAP routines work in the PDS900 emulator but not in a real device - why? |
|
We suggest that you familiarise yourself with the "PDS900 IAP Applications note" (accessed through the Help menu).
There are two points that you need to take careful note of that could cause a Flash write operation to fail:
1) If you are running interrupts and interleaving code Flash write functions amongst them then ensure that the OI error code returned is correctly processed.
2) If you are performing advanced power management with BOE programmed but enable or disable the brownout detector with the BOPD bit, then ensure that the detector is enabled prior to performing an Flash write operation.
The data sheet is quite explicit in that the error code returned from the IAP calls should be examined and correctly processed.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FAQ |
|
|
What other payment methods are available? |
|
We accept Visa and Mastercard. We cannot process American Express transactions at present.
If you wish to pay by international bank draft, proceed with your order as if you were paying by credit card, but indicate you will be sending a bank draft in the "Special instructons" section of the order form.
If you wish, we can fax a commercial invoice before proceeding with the order.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FAQ |
|
|
Being based in New Zealand, aren't your shipping costs higher? |
|
It does cost more to ship from NZ to Eurpoe than from say, the United States?
Because the emulation tools are a reasonable outlay, we always ship via courier, always to a physical address (we will not ship to a P.O. Box) and the shipments are insured.
If your order contains only lower-value items such as bondout replacements you can elect to ship vis standard air post. It takes a little longer but is significantly cheaper.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FAQ |
|
|
I don't like supplying my credit card details via the web. |
|
Our credit card transaction is secure and all credit card details are encrypted. If you prefer however you can fax or email your credit card details instead to
+64 9 415-3514
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FAQ |
|
|
Will I have to pay any additional costs? |
|
At the time your order is fulfilled, you will be charged for the goods, shipping and insurance. Some countries will require duties or taxes to be paid before the goods can clear your local customs. We cannot predict when your customs service will levy these charges, or what the extra amount, if any, will be.
If you wish, we can fax you a commercial invoice before your order is fulfilled. The amount shown on this will be for the goods, shipping and insurance, but will exclude any of the levies discussed above. If in doubt, we recommend checking with your local customs agent in case there will be duty or tax payable also. To have us fax you a commercial invoice, just place your order as usual and leave the payment details blank.
Note also that if you are paying by bank draft, the issuing bank (I.e. your bank) will most probably add a fee for this service. The amount remitted to us must take account of any fee your bank might charge
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FAQ |
|
|
When will my card be debited? |
|
Authorization will be obtained at the time the order is placed, however, your card will not be debited until after before the goods have been shipped, and generally not before they reach their destination.
We do not use automatic credit card transactions. All orders are checked and credit card authorisation obtained by phone.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FAQ |
|
|
Why can't I select the option for delivery by post instead of courier? |
|
If your order only contains items that can be shipped by standard air post without difficulty, then you will see this option displayed when you enter your shipping details.
Higher-values items such as emulation systems are only shipped by courier and these shipments are always insured. The option allowing you to select the shipping option will be grayed out in this case.
If your order only includes spare chips or bondout replacements, you will be able to select an option to have the goods sent by air post.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FAQ |
|
|
Our company has specific procedures for receiving packages - what details can you supply us about the shipment. |
|
We appreciate that security concerns mean most companies have specific procedures for receiving inwards goods. Acqura products are shipped in cartons clearly marked as originating from us. A commercail invoice/customs declaration is attached to the outside of the package.
At the time shipment is sent, you will be emailed with the full shipment details, including the airway bill number, the size of package and the estimated arrival date. The airway bill number can be used to track the shipment on the web at www.tnt.com.
If your company has specific requirements for inwards goods, please let us know at the time you place the order or email us at orders@acqura.com.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FAQ |
|
|
Does your site use Cookies? |
|
A cookie is a small text file written to your disk by your browser.
There are two types of cookies: session cookies and persistent cookies. Session cookies are used to store temporary information about your visit to a particular Web site -- in Acqura's case, we use them to provide a unique identifier for your "shopping cart" while you browse products.
We also make use of persistent cookies to store information like your company name and shipping address between visits, so that you don't have to re-enter them each time. We stress that this cookie information is stored on your local hard disk, not on our web site.
Both types of Cookies are generally beneficial and secure. When a Cookie is issued to you by one site it can only be requested by that same site, so there is no security risk of information being shared between sites. Additionally, the use of cookies enables Web sites to remember your preferences automatically, as well as adding other automatic features.
The idea that cookies violate privacy is a myth. Instead, you can use them to your advantage. These days, enough sites rely on cookies, and since sites can only read their own cookies, it makes sense to have cookies enabled by default.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FAQ |
|
|
I Need a Pro-forma Invoice/Quotation before I can order |
|
If you require a Pro Forma Invoice/Quotation, please place your order as normal and leave the credit card details section blank. Indicate that a Pro Forma is required in the 'Special Instructions' field of the order and one will be faxed to you within one business day.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FAQ |
|
|
What is your privacy policy? |
|
Acqura Systems Privacy Policy
As part of order fulfillment, we require a valid email address to be provided. This email address is used to provide acknowledgement of your order and keep you updated on the order progress. Customer email addresses are also recorded as part of Acqura's support program.
No email addresses or other customer details are stored on our web server nor on any other machine connected to the Internet. All order details are transmitted by encrypted email. Credit card details, if provided, are not stored other than in encrypted form.
We will not sell, lend. give your email address nor any other details to anyone, ever.
Any information emailed to you will be related to support or updates of Acqura products. You may choose at any time not to receive this information.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FAQ |
|
|
Who are Acqura Systems? |
|
Acqura systems is the web trading division of a New Zealand company - Applied Digital Research Ltd. We have been trading since 1985 and specialise in quality low-cost emulation tools for the Philips 8xC51 family of microcontrollers.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FAQ |
|
|
I'm from New Zealand - what about GST? |
|
If you provide a shipping address within New Zealand then Goods and Services Tax (GST) will be payable in addidion to the totals shown. The prices shown on Acqura are all in US dollars. These will be converted to NZ dollars at the rate on the day payment is effected and GST (currently 12.5%) will be added.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FAQ |
|
|
What is your VAT number? |
|
Acqura Systems is a wholly owned subsidiary of a New Zealand registered company, Applied Digital Research Limited. New Zealand companies are registered with the Inland Revenue Department through GST (Goods and Services Tax) numbers. This is is similar to the United Kingdom's VAT number.
Our GST number is 59-417-797.
This number is printed on all commercial stationery.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FAQ |
|
|
"Why does the amount charged to my card differ slightly from the amount shown when I ordered?" |
|
If you are paying by credit card then the amount charged to your card may differ slightly from that amount shown when you place the order.
When your order is processed, the $US amount charged is converted to $NZ at the prevailing exchange rate, minus a cushion in your favor of 1.5%. When the charge is levied on your card, your bank will convert the $NZ amount to your currency at that prevailing exchange rate. If the rates have shifted (either between the $US and $NZ or between your currency and the $NZ) then the amount charged to your card will differ from the amount shown when you order.
In most cases the differences are minor unless the exchange rates change significantly between when the order is placed and when the card is debited.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FAQ |
|
|
How can I find out the shipping costs for an order? |
|
We calculate the shipping and insurance costs after you have supplied delivery address details. You can find out these costs by 'pretending' to place your order.
When you have placed all items youy require into your shopping cart, click on the checkout icon. This takes you to a screen where you can enter the shipping details and preferred method of shipping. Once you have done this, click on the button marked Click to Proceed. The next screen displayed is where you would normally enter your payment details and will also show the shipping and insurance charges for your order.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FAQ |
|
|
Why should I buy a Temprecord logger? |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FAQ |
|
|
Choose from the following |
|
|
|
|
|
|
|
|
|
|
|
|
|
