AN1814 APPLICATION NOTE

Transcription

1 AN1814 APPLICATION NOTE USB Demonstration for DK3200 with µpsd3234a (Inside View of Windows Demo-Application) The µpsd32xx family, from ST, consists of Flash programmable system devices with a 8032 Microcontroller Core. Of these, the µpsd3234a and µpsd3254a are notable for having a complete implementation of the USB hardware directly on the chip, complying with the Universal Serial Bus Specification, Revision 1.1. This application note describes a demonstration program that has been written for the DK3200 hardware demonstration kit (incorporating a µpsd3234a device). It gives the user an idea of how simple it is to work with the device, using the HID class as a ready-made device driver for the USB connection. IN-APPLICATION-PROGRAMMING (IAP) AND IN-SYSTEM-PROGRAMMING (ISP) Since the µpsd contains two independent Flash memory arrays, the Micro Controller Unit (MCU) can execute code from one memory while erasing and programming the other. Product firmware updates in the field can be reliably performed over any communication channel (such as CAN, Ethernet, UART, J1850) using this unique architecture. For In-Application-Programming (IAP), all code is updated through the MCU. The main advantage for the user is that the firmware can be updated remotely. The target application runs and takes care on its own program code and data memory. IAP is not the only method to program the firmware in µpsd devices. They can also be programmed using In-System-Programming (ISP). A IEEE compliant JTAG interface is included on the µpsd. With this, the entire device can be rapidly programmed while soldered to the circuit board (Main Flash memory, Secondary Boot Flash memory, the PLD, and all configuration areas). This requires no MCU participation. The MCU is completely bypassed. So, the µpsd can be programmed or reprogrammed any time, any where, even when completely uncommitted. Both methods take place with the device in its normal hardware environment, soldered to a printed circuit board. The IAP method cannot be used without previous use of ISP, because IAP utilizes a small amount of resident code to receive the service commands, and to perform the desired operations. HID CLASS The Human Interface Device (HID) class is a standard classification for the USB. It was designed as a common device driver for interface devices such as the mouse, tablet and keyboard, and sports equipment, medical instruments, and various other measurement and audio/visual devices. This application note describes a demonstration program that utilizes the HID.DLL library, which Microsoft supports in its operation systems. It shows how simple it can all be, avoiding even the need to write a specific device driver. May /20

2 Initialization and De-initialization of HID Class Functions In the main program, the HID.DLL is initialized dynamically, using a call to the WinAPI function LoadLibrary(), and its functions are set up using GetProcAddress(). The LoadLibrary function maps the specified executable module into the address space of the calling process. If the function succeeds, the return value is a handle to the module. Otherwise, the return value is NULL, and an error message is generated. hhid = LoadLibrary("HID.DLL"); if (!hhid) OnError("Failed to load HID.DLL."); The GetProcAddress function returns the address of the specified exported dynamiclink library (DLL) function. We export only those functions that are needed. HidD_GetProductString = (PHidD_GetProductString) GetProcAddress(hHID, "HidD_GetProductString"); HidD_GetHidGuid = (PHidD_GetHidGuid) GetProcAddress(hHID, "HidD_GetHidGuid"); HidD_GetAttributes = (PHidD_GetAttributes) GetProcAddress(hHID, "HidD_GetAttributes"); HidD_SetFeature = (PHidD_SetFeature) GetProcAddress(hHID, "HidD_SetFeature"); HidD_GetFeature = (PHidD_GetFeature) GetProcAddress(hHID, "HidD_GetFeature"); A test then follows, to check that all the functions point to some valid address (not NULL). If any of them is set to NULL, it means that GetProcAddress() did not find the requested function in the DLL, and an error message is generated. if (!HidD_GetHidGuid!HidD_GetAttributes!HidD_GetProductString!HidD_SetFeature!HidD_GetFeature ) OnError("Couldn t find one or more HID entry points."); FreeLibrary(hHID); When the user closes the program, the HID.DLL is de-initialized, simply by closing the handle of the library. FreeLibrary(hHID); 2/20

3 Searching for the USB Device The typical Windows XP Hardware Insert sound, that you hear whenever you plug a USB device into your computer, is generated as an indication that the device has been recognized by the operating system in a process called enumeration. This process involves tasks such as: retrieving a standard set of descriptors from the device, and setting standard device parameters. The device supplies an HID class descriptor, which contains the HID specification information, and the length of the HID report descriptor. A report descriptor defines the format, and uses of the data, thereby defining the purpose of the device. When the demonstration device has correctly handled the requests and HID specific parameters, it is ready to be used by the application. But at first, it has to be found among a number of other devices that could be attached to the computer. The function OpenDeviceHandle() in the demonstration program takes care of this process. It browses through all the USB devices that are present, and requests their identification data (such as vendor ID and product ID). These two values are sufficient to determine whether it is the desired device or not. If none of the devices match the expected vendor and product ID, it probably means that the device we are searching for is not plugged in, or is powered off, or has failed the enumeration. Otherwise the application attempts to open the device. This is a multi-step process. 1. Obtain the Windows GUID (globally unique ID) for HID devices. The call to the HidD_GetHidGuid() function is used for this purpose. GUID guid; // GUID structure holds a globally unique identifier (GUID), (HidD_GetHidGuid)(&guid); // which identifies a particular object class and interface. 2. Get an array of structures containing information about all attached HIDs. The call to function Setup- DiGetClassDevs() is used. This step uses the previously obtained HID GUID to ensure that the list contains only HID devices. HDEVINFO hdevinfo;// Open handle to the set of all HID devices hdevinfo = SetupDiGetClassDevs( &guid, NULL, NULL, DIGCF_PRESENT DIGCF_INTERFACEDEVICE); if (hdevinfo == INVALID_HANDLE_VALUE) OnError("Failed to open handle to HID device set."); return 0; 3/20

4 3. Get information about each device in the list until one with the correct VID and PID is found. The call to the SetupDiEnumDeviceInterfaces() function is used. If this function returns false, it means that the end of the list has been reached without finding the desired device. DWORD dwindex = 0; bool success; while (1)// For each HID device... success = SetupDiEnumDeviceInterfaces(hDevInfo, 0, &guid, dwindex, &devdata); if (success == FALSE) return 0; // no more devices found dwindex++; // code for request informations (step 4) & opening a handle to device (step 5) goes here 4. Request detailed data using the function about the device indexed in the previous step. The DetailData structure contains parameter DevicePath, which will be used to open the device in the next step. The SetupDiGetDeviceInterfaceDetail() function serves for this purpose. DetailData.cbSize = 5; unsigned long BytesReturned; success = SetupDiGetDeviceInterfaceDetail(hDevInfo, &devdata, &DetailData, 256, &BytesReturned, NULL); if (success) //code for opening a handle to device (step 5) goes here 4/20

5 5. Call the Windows API function, CreateFile(), to open the device using the path obtained in the previous step. This function returns the handle to the device, or, if it failed, returns NULL. HANDLE hdevice = CreateFile(DetailData.DevicePath, GENERIC_READ GENERIC_WRITE, FILE_SHARE_READ FILE_SHARE_WRITE, NULL, OPEN_EXISTING, 0, NULL); if (hdevice!= INVALID_HANDLE_VALUE) // code for getting of vendor and product ID values goes here 6. Get and compare the Vendor ID and Product ID of the open device to determine whether this is the device we are searching for. If so, the handle and the path are stored in global variables. Otherwise, the handle is closed, and the test continues on next device in the list (steps 4 to 6). HIDD_ATTRIBUTES attr; attr.size = sizeof(attr); if ((g_phidd_getattributes)(hdevice, &attr)) if ((attr.vendorid == ST_VENDOR_ID) && (attr.productid == ST_PRODUCT_ID)) // Found our device! Store handle and device name. g_hdevice = hdevice; strcpy(g_devicepath, DetailData.DevicePath); SetupDiDestroyDeviceInfoList(hDevInfo); return 1; // otherwise close the handle and continue with next device in list CloseHandle(hDevice); Creating and Stopping the Mirror Thread The main application should stay responsive even while waiting for USB data transfers. Therefore, it is desirable to put the USB Reads and Writes in a separate thread. This feature allows the main application to continue processing messages while the USB transaction thread waits for transactions to complete. In the demonstration program, the mirror thread is a good example of this method. In the main dialogue window, it displays the copy of the demonstration kit s LCD display contents. In the CreateInputThread() function, the InputThreadProc() function is executed in a new thread. The WinAPI function, CreateThread(), serves for this purpose. On success, this function returns the handle to 5/20

6 the new thread. If the thread cannot be created, the function returns NULL, and an error message is generated. DWORD dwthreadid; HANDLE hthread = CreateThread(NULL, 0, InputThreadProc, NULL, 0, &dwthreadid); if (!hthread) OnError("Failed to create input thread."); return hthread; // The function returns handle to the created thread. The name of the function InputThreadProc() appears among the parameters of CreateThread() function. This is the code to be executed in the new thread. Because the USB connection will be shared between the main and mirroring threads, another handle to the device is needed. It will be opened with the CreateFile() function, too; but here, in addition, the FILE_FLAG_OVERLAPPED parameter is used. This allows the application to perform overlapped reading and writing. HANDLE hdevice = CreateFile(g_devicePath, GENERIC_READ GENERIC_WRITE, FILE_SHARE_READ FILE_SHARE_WRITE, NULL, OPEN_EXISTING, FILE_FLAG_OVERLAPPED, NULL); The next step is the initialization of OVERLAPPED structure, which will be needed in asynchronous input and output. In every use of the ReadFile() and WriteFile() functions, this structure will be passed as a parameter. OVERLAPPED ol; memset(&ol, 0, sizeof(ol)); To indicate whether data transfer has been completed, we need to create an event. It is set to the signalled state by the ReadFile() and WriteFile() functions, and is reset by the calling thread before initiating the data transfer. ol.hevent = CreateEvent(NULL, TRUE, FALSE, NULL); Finally, we need the buffer for storing the received data. The whole image of the LCD cannot be transferred in one go; multiple consecutive packets have to be used. This is because only eight bytes can be transferred in one USB packet. The following code shows how the buffer is initialized and cleared. static char lcdbuffer[lcd_buffer_size + 1]; memset(lcdbuffer, 0, sizeof(lcdbuffer)); The body of the input thread is placed in an infinite loop. For better readability, some parts of code (especially those that are needed for synchronization) are bypassed. In the first half of following code, the input 6/20

7 report buffer is prepared, and using the ReadFile() function, the data is received. Then this data is stored in the LCD mirror buffer: at the position indicated by the first byte, the following seven bytes are written. Finally, the UpdateDisplay() function is called, to display the mirrored LCD data to the panel in the main form s window. while (TRUE) // Report buffer (Windows will put a report ID byte at the start) char report[input_report_size + 1]; // Read input report from device DWORD cbret; ResetEvent(ol.hEvent); BOOL bret; bret = ReadFile(hDevice, report, sizeof(report), &cbret, &ol); // Update LCD display mirror int bufindex = report[1]; int nbytes = INPUT_REPORT_SIZE - 1; // this is to protect from buffer overflow if (bufindex + nbytes > LCD_BUFFER_SIZE) nbytes = LCD_BUFFER_SIZE - bufindex; if (nbytes < 0) nbytes = 0; memcpy(lcdbuffer + bufindex, report + 2, nbytes); UpdateDisplay(lcdBuffer); The implementation of UpdateDisplay() function is very simple. void fastcall UpdateDisplay(char *src) src[lcd_buffer_size-1] = 0; mainform->lbdisplaymirror->caption = AnsiString(src); When user closes the program, or clicks the Stop Mirror button, the input thread is stopped in this way: SetEvent(g_hStopEvent);// set the state of the specified event object to signaled CloseHandle(hInputThread);// close the input thread s handle hinputthread = NULL;// clear the handle variable 7/20

8 INPUT AND OUTPUT REPORTS An input report was mentioned in previous section. This needs some further explanation. Using USB terminology, the report is synonymous with an elementary data transfer. Three types of reports exist: Input, Output or Feature. The host receives data in Input reports and sends data in Output reports. Feature reports may travel in either direction. All HID data must use a specific report format that defines the size and contents of the data in the report. A report descriptor in the device s firmware describes the report, and may also include information about how the receiver of the data should use it. The report can consist of one or several packets. For low-speed devices, like µpsd, the size of the packet is limited to eight bytes. In the demonstration, an input report fits into one packet, and output and feature reports are 64 bytes in length, and are sent in eight packets. See report sizes definition in app_intr.h: #define INPUT_REPORT_SIZE8 #define OUTPUT_REPORT_SIZE64 #define FEATURE_REPORT_SIZE(OUTPUT_REPORT_SIZE) #define CMD_SIZE(OUTPUT_REPORT_SIZE) Regarding the transfer rate, no more than one transaction per 10 milliseconds is guaranteed for low-speed devices. This gives a maximum of 800 bytes per second. Commands over the USB Connection The application needs to be able to read input reports and to write output reports. To perform these tasks as mentioned before, the ReadFile() and WriteFile() functions are used. Each of these functions uses the device handle that is created by CreateFile() function. In addition, the application uses overlapped transactions, which allows a low-cpu-overhead state to be entered while waiting for a requested USB transaction to occur. Otherwise, the application would have to wait until the USB transaction had finished before it could perform any additional tasks. This would not be desirable, because the application would spend most of its time waiting for data. The meaning of the individual bytes in a report is application-dependent. Feature and output report structures, as is defined in file app_intr.h, use the union construct to describe them. typedef struct union uchar cmd;// CMD_xxx code struct uchar cmd;// CMD_ERASE uchar flash;// PRIMARY_FLASH or SECONDARY_FLASH uint16 address;// Any address in any sector erase; struct uchar cmd;// CMD_READ or CMD_WRITE 8/20

9 uchar flash;// PRIMARY_FLASH or SECONDARY_FLASH uint16 address;// Target xdata address uint16 nbytes;// Num bytes to read/write rw; struct uchar cmd;// CMD_SET_xxx uchar page;// Desired page register value uchar vm;// Desired VM register value setregs; struct uchar cmd;// CMD_GET_STATUS uchar currentcmd;// Returns current command being processed uchar page;// Returns page register value uchar vm;// Returns VM register value uchar ret;// Return value from flash routine uchar checksum;// Check sum for write commands status; uchar buffer[cmd_size]; u; MCU_CMD, *PMCU_CMD; This is the most efficient way to define the output report buffer. It enables access to individual bytes, through names varying from command to command. For example, the second byte in CMD_ERASE, CMD_READ or CMD_WRITE indicates which Flash memory the operation concerns (primary or secondary), but in CMD_SET_VM or CMD_SET_PAGE this byte contains the page register value. The MCU_CMD structure is part of the REPORT_BUF structure, defined in the main source file USB_Demo.cpp. This is because the first byte of the report contains the Report ID value. The size of complete structure is 65 bytes, and it has to be exact, because the HID driver expects report buffers of this size, otherwise the call to WriteFile() will fail. typedef struct // The Microsoft HID driver expects a prefix report ID byte unsigned char reportid; MCU_CMD report; REPORT_BUF, *PREPORT_BUF; Be careful, while compiling your application, to use proper data types. Also be careful with the compiler options: data alignments other than single-byte may cause problems. 9/20

10 Eight commands are enough to support the IAP operations: #define CMD_RESET0x01 #define CMD_ERASE0x02 #define CMD_WRITE0x03 #define CMD_READ0x04 #define CMD_STATUS0x05 #define CMD_SET_REGS0x06 #define CMD_SET_PAGE0x07 #define CMD_SET_VM0x08 The mechanism of creating an output report, with the command and its embedded parameters, we will clarify on a SET_PAGE command. The function SetPage() serves for this purpose. BOOL SetPage(BYTE page); The function takes one argument: the new value for the PAGE register of the µpsd. The function returns TRUE if successful, FALSE if there is an error. (If the sending of the command fails, the error message is displayed in addition). First, the buffer needs to be initialized and its content cleared. REPORT_BUF reportbuf; memset(&reportbuf, 0, sizeof(report_buf)); Then, the individual bytes will be filled with the new values. The byte, at position zero, is cleared. The byte, at position one, contains the value of the command (CMD_SET_PAGE, defined to 07h), and the byte, at position two, identifies the destination sector (which can be 0 to 7 for primary, and 0 to 3 for secondary Flash memory). reportbuf.reportid = 0; reportbuf.report.u.setregs.cmd = CMD_SET_PAGE; reportbuf.report.u.setregs.page = page; Finally, the output report is sent to the device. If there is an error, the function WriteFile() returns FALSE and an error message is generated. DWORD cbwritten; if (!WriteFile(g_hDevice, &reportbuf, sizeof(report_buf), &cbwritten, NULL)) OnError("Error sending CMD_SET_PAGE command."); return FALSE; return TRUE; 10/20

11 The variable, cbwritten, contains the amount of data successfully written, but in this implementation there is no need to check it. Data Transfers over the USB Connection While SET_PAGE command needs only a few bytes to be transported, some other operations require larger amounts of data. The ReadFlash() function reads the given number of bytes from the selected Flash memory sector, starting at a specified offset, and stores it in a buffer. The function requires five parameters: flash selects between: 0: main, primary, Flash memory and 1: boot, secondary, Flash memory sector has the same meaning (destination sector) as was explained in SetPage(): 0 to 7 for primary Flash memory, and 0 to 3 for secondary Flash memory. offset contains the destination address for writing the data 0000h to 7FFFh for main Flash memory 0000h to 1FFFh for boot Flash memory *buffer is a pointer to the destination buffer, where the read data will be stored. nbytes sets the amount of data to be read. As usual, the function returns TRUE on successful completion, or FALSE if there is an error. BOOL ReadFlash(uchar flash, uchar sector, uint16 offset, uchar *buffer, uint16 nbytes); Inside the function, the output buffer is first prepared. Then, the sector offset is converted to xdata address using the OffsetToAddress() function. REPORT_BUF reportbuf; memset(&reportbuf, 0, sizeof(report_buf)); uint16 address = OffsetToAddress(flash, sector, offset); Now the desired command, with its parameters, is set up in the output report, and the command is sent in the usual way. reportbuf.reportid= 0; reportbuf.report.u.cmd= CMD_READ; reportbuf.report.u.rw.flash= flash; reportbuf.report.u.rw.address= SWAP_UINT16(address); reportbuf.report.u.rw.nbytes = SWAP_UINT16(nBytes); DWORD cbwritten; if (!WriteFile(g_hDevice, &reportbuf, sizeof(report_buf), &cbwritten, NULL)) 11/20

12 OnError("Error sending CMD_READ command."); LeaveCriticalSection(&g_crSection); return FALSE; After receiving of the command, the device answers almost immediately. The requested amount of data is sent sequentially, for which a while cycle is used. For the transfer from device to computer, a feature report is used. The HidD_GetFeature() function, from HID.DLL, serves for reading such reports from the device. uint16 cbremaining = nbytes; uint16 cbtemp = cbremaining; while (cbremaining) if (!(HidD_GetFeature)(g_hDevice, &reportbuf, sizeof(report_buf))) OnError("Error reading CMD_READ reply."); LeaveCriticalSection(&g_crSection); return FALSE; // code for processing of received data and displaying the status goes here The received data is then stored in a buffer, and the command byte, at position zero, is skipped. uint16 cbdata = min(cbremaining, CMD_SIZE - 1); memcpy(buffer, reportbuf.report.u.buffer + 1, cbdata); buffer += cbdata; cbremaining -= cbdata; When the value of cbremaining reaches zero, the reading cycle ends, and the function exits. Implementation of Other IAP Commands The implementation of WriteFlash(), SectorErase(), ResetBoard() and SetVM() is very similar to the two functions that are described above. Higher-level IAP functions use one or more basic IAP functions: WriteData() uses SelectFlash() and WriteFlash(). ReadData(), UploadToFile() and BlankCheck() use SelectFlash() and ReadFlash(). ProgramOrVerify() uses SelectFlash(), ReadFlash() and WriteFlash(). Some of the IAP functions can be directly mapped on to button-click events, and some need to display additional dialogues or message boxes. However, the functionality of the buttons is easy to understand, and obvious from the implementation. For example, the Program button executes the following code: 12/20

13 First, the user is prompted for a file name from which to read the data. Then, the IAP command is invoked. Finally, the text in the status panel is updated. if (OpenDialog1->Execute()) if (ProgramOrVerify(SELECTED_FLASH, SELECTED_SECTOR, FALSE, OpenDialog1->FileName.c_str())) mainform->sbstatus->panels->items[0]->text = "Program Sector is done."; The implementation of the other buttons is very similar. 13/20

14 OVERVIEW OF USB IAP DEMO APPLICATION After starting the demonstration application, you see that when the board is not connected, you can do almost nothing. The application now searches for the demonstration board on the USB ports. If the program remains in this state, it is probably because the board is not plugged in, or is not powered. Figure 1. Making a Connection to the Board When connection to the board is established, the mirroring thread runs immediately. Everything that appears on board s LCD is also shown (mirrored) on the demonstration application s window. If you change from Main to Boot Flash memory, and back again, you should see how firmware execution source is reported in the two places. Figure 2. Mirroring of LCD Content 14/20

15 Now, click on the Read button. See how the parameters are set: offset is 0000h, count is 10h, source Flash memory is Main, and the sector is 1. This will read the first 16 bytes (10h) from the start of the FS1 Flash memory sector. Figure 3 shows what will appear if the memory is empty. Figure 3. Reading Data from Memory Now try to write some bytes. Fill the Data field with several hexadecimal values. The Count field will be updated automatically. Set the destination offset to 0200h, for example, and press the Write button. The status message, in status bar, informs you whether the operation was successful. Figure 4. Writing Data to Memory 15/20

16 Another useful IAP function is Blank Check. If you want to write some data to Flash memory, the memory should first be empty (erased). Press the Blank Check button, and it will indicate that the memory is not empty, and that there is some data (at the address where you have just written it). Figure 5. Blank Checking To erase this sector, again, simply press the Erase button. Again, the status message, in status bar, informs you whether the operation was successful. Figure 6. Erasing the Sector Now you can press Read button again, and see that data were erased and the memory is, again, empty. Alternatively, run Blank Check again, and notice the result. 16/20

17 Figure 7. Reading Data from Memory again Now look at Sector 0: set offset to 0000h, count to 10h, change Sector to 0, and press the Read button. You can see some data there. This is the code of IAP demo firmware. Using the Upload button, you can save this code to a file. (The application will ask you for the file name to be given to it). Figure 8. Uploading the Sector Content The file is saved in IntelHEX format. It is a standard ASCII file, and can be opened in any editor or viewer. It starts with the data from the start of sector 0: : b727430f07f017e00d3ef9400ee6437 : e4fdfc0dbd00010cbc02f88d : bd58f5ef1f70e31e80e d2d2ea25 : ff0204ab902145ebf0a3eaf0a3e912 17/20

18 Now you can try to program this data to Sector 1 (which you have previously erased, in Figure 6). Change the sector selector to 1, and press the Program button. The application will ask for the file name from which it will load the data. Give it the file name that you used in the previous step. Figure 9. Programming Data to Sector After programming is finished, the application informs you of the fact, and how much time it took. Press the Read button, again, to see that the data are really there. Figure 10. Reading Data from Memory, yet again If you want to be sure that all data was written correctly, use the Verify button. Use the same file name that you used for the Program command. The verification result is displayed in a message box. 18/20

19 Figure 11. Verifying the Sector Content with a File Other Commands Feel free to try the other buttons. Reset sends an IAP command to reset the board. Disconnect stops the communication between the board and the application. (This is only software disconnect, though, so you do not hear the Windows XP s unplug sound). Stop Mirror can temporarily stop the mirroring thread. Finally, the Close button can be used to close the application. CONCLUSION This Windows-based IAP demonstration program for the µpsd3234a product is written using general purpose IAP routines that a customer could use in his or her own, applications. These routines are very flexible, with their configuration options, and can be used in a variety of configurations, and yet remain easy to work with. REVISION HISTORY Table 1. Document Revision History Date Version Revision Details 27-May First Issue 19/20

20 For current information on ST PSD products, please consult our pages on the world wide web: If you have any questions or suggestions concerning the matters raised in this document, please send them to the following electronic mail addresses: (for application support) (for general enquiries) Please remember to include your name, company, location, telephone number and fax number. Information furnished is believed to be accurate and reliable. However, STMicroelectronics assumes no responsibility for the consequences of use of such information nor for any infringement of patents or other rights of third parties which may result from its use. No license is granted by implication or otherwise under any patent or patent rights of STMicroelectronics. Specifications mentioned in this publication are subject to change without notice. This publication supersedes and replaces all information previously supplied. STMicroelectronics products are not authorized for use as critical components in life support devices or systems without express written approval of STMicroelectronics. The ST logo is a registered trademark of STMicroelectronics. All other names are the property of their respective owners 2004 STMicroelectronics - All rights reserved STMicroelectronics GROUP OF COMPANIES Australia - Belgium - Brazil - Canada - China - Czech Republic - Finland - France - Germany - Hong Kong - India - Israel - Italy - Japan - Malaysia - Malta - Morocco - Singapore - Spain - Sweden - Switzerland - United Kingdom - United States 20/20