Emulator Vs Port

0 views

Skip to first unread message

Danny Hosford

unread,

Aug 3, 2024, 5:57:20 PM8/3/24

to carprabgueblet

MSP430G2

I recently acquired an MSP430 launchpad and have been eager to make it work. Unfortunately, nothing seems to work. I have been trying to download a piece of code that I wrote but I keep getting the above error. I have tried using the IAR IDE,l but I also get an error similar to the above one.

I know this isn't really a fix for your problem, but I have to make one point because I had the same error and it was stumping me for a while, There really ought to be a troubleshooter sticky for dummies like me.

According to TI, when the Launchpad G2 is plugged into USB port, the driver and other DLLs for that device are "automatically" installed if you have CCS or IAR in the system. But your experience seems to indicate that CCS or IAR will try to find "MSP-FET430UIF" and could not find that.

I have this same issue. CCS v5.2 will not allow me to access my LaunchPad. I get the same error message all the time. It had worked before, then i did a project using a real FET430UIF for a while. Now I don't have the FET430UIF connected any more, and it won't let me talk to the LaunchPad. I tried all the suggestions above, to no avail. Why does it think I have an FET430UIF? I can't find anywhere that the tool type is set to FET430UIF. It is as if it decided on its own that since I used an FET430UIF once, I am no longer allowed to use LaunchPad!

OK, found the problem. I have another USB device from another vendor that can't be plugged in at the same time. It doesn't indicate any problem, but the two can't co-exist, or CCS thinks my LaunchPad is an FET430UIF!

The Azurite open-source emulator provides a free local environment for testing your Azure Blob, Queue Storage, and Table Storage applications. When you're satisfied with how your application is working locally, switch to using an Azure Storage account in the cloud. The emulator provides cross-platform support on Windows, Linux, and macOS.

Azurite is automatically available with Visual Studio 2022. The Azurite executable is updated as part of Visual Studio new version releases. If you're running an earlier version of Visual Studio, you can install Azurite by using either Node Package Manager (npm), DockerHub, or by cloning the Azurite GitHub repository.

This installation method requires that you have Node.js version 8.0 or later installed. Node Package Manager (npm) is the package management tool included with every Node.js installation. After installing Node.js, execute the following npm command to install Azurite.

To use Azurite with most project types in Visual Studio, you first need to run the Azurite executable. Once the executable is running, Azurite listens for connection requests from the application. To learn more, see Running Azurite from the command line.

For Azure Functions projects and ASP.NET projects, you can choose to configure the project to start Azurite automatically. This configuration is done during the project setup. While this project configuration starts Azurite automatically, Visual Studio doesn't expose detailed Azurite configuration options. To customize detailed Azurite configuration options, run the Azurite executable before launching Visual Studio.

After you create the project, Azurite starts automatically. The location of the Azurite executable file is detailed in the Azurite executable file location table. The output looks similar to the following screenshot:

When the configuration completes, select Close, and the Azurite emulator starts automatically. The location of the Azurite executable file is detailed in the Azurite executable file location table. The output looks similar to the following screenshot:

Azurite cannot be run from the command line if you only installed the Visual Studio Code extension. Instead, use the Visual Studio Code command palette to run commands. Configuration settings are detailed at Configure Azurite extension settings.

Optional - Azurite stores data to the local disk during execution. Use the -l or --location switch to specify a path as the workspace location. By default, the current process working directory is used. Note the lowercase 'l'.

Optional - The debug log includes detailed information on every request and exception stack trace. Enable the debug log by providing a valid local file path to the -d or --debug switch.

Optional - By default, Azurite uses the HTTP protocol. You can enable HTTPS mode by providing a path to a Privacy Enhanced Mail (.pem) or Personal Information Exchange (.pfx) certificate file to the --cert switch. HTTPS is required to connect to Azurite using OAuth authentication.

Azurite supports basic authentication by specifying the basic parameter to the --oauth switch. Azurite performs basic authentication, like validating the incoming bearer token, checking the issuer, audience, and expiry. Azurite doesn't check the token signature or permissions. To learn more about authorization, see Authorization for tools and SDKs.

Optional. When using the fully qualified domain name instead of the IP in request Uri host, by default Azurite parses the storage account name from request URI host. You can force the parsing of the storage account name from request URI path by using --disableProductStyleUrl:

Optional. By default, blob and queue metadata is persisted to disk and content is persisted to extent files. Table storage persists all data to disk. You can disable persisting any data to disk and only store data in-memory. In the in-memory persistence scenario, if the Azurite process is terminated, all data is lost. The default persistence behavior can be overridden using the following option:

Optional. By default, the in-memory extent store (for blob and queue content) is limited to 50% of the total memory on the host machine. The total is evaluated using os.totalmem(). This limit can be overridden using the following option:

There's no restriction on the value specified for this option, but virtual memory might be used if the limit exceeds the amount of available physical memory as provided by the operating system. A high limit might eventually lead to out of memory errors or reduced performance. This option is rejected when --inMemoryPersistence isn't specified.

You can connect to Azurite from Azure Storage SDKs, or tools like Azure Storage Explorer. Authentication is required, and Azurite supports authorization with OAuth, Shared Key, and shared access signatures (SAS). Azurite also supports anonymous access to public containers.

Azurite refreshes custom account names and keys from the environment variable every minute by default. With this feature, you can dynamically rotate the account key, or add new storage accounts without restarting Azurite.

The default devstoreaccount1 storage account is disabled when you set custom storage accounts. If you want to continue using devstoreaccount1 after enabling custom storage accounts, you need to add it to the list of custom accounts and keys in the AZURITE_ACCOUNTS environment variable.

The easiest way to connect to Azurite from your application is to configure a connection string in your application's configuration file that references the shortcut UseDevelopmentStorage=true. Here's an example of a connection string in an app.config file:

The following examples show how to authorize a BlobContainerClient object using three different authorization mechanisms: DefaultAzureCredential, connection string, and shared key. DefaultAzureCredential provides a Bearer token-based authentication mechanism, and uses a chain of credential types used for authentication. Once authenticated, this credential provides the OAuth token as part of client instantiation. To learn more, see the DefaultAzureCredential class reference.

The following examples show how to create and authorize a QueueClient object using three different authorization mechanisms: DefaultAzureCredential, connection string, and shared key. DefaultAzureCredential provides a Bearer token-based authentication mechanism, and uses a chain of credential types used for authentication. Once authenticated, this credential provides the OAuth token as part of client instantiation. To learn more, see the DefaultAzureCredential class reference.

The following examples show how to create and authorize a TableClient object using three different authorization mechanisms: DefaultAzureCredential, connection string, and shared key. DefaultAzureCredential provides a Bearer token-based authentication mechanism, and uses a chain of credential types used for authentication. Once authenticated, this credential provides the OAuth token as part of client instantiation. To learn more, see the DefaultAzureCredential class reference.

By default, Storage Explorer doesn't open an HTTPS endpoint that uses a self-signed certificate. If you're running Azurite with HTTPS, you're likely using a self-signed certificate. In Storage Explorer, import SSL certificates via the Edit -> SSL Certificates -> Import Certificates dialog.

The service endpoints for Azurite are different from the endpoints of an Azure Storage account. The local computer doesn't do domain name resolution, requiring Azurite endpoints to be local addresses.

By default, when using Azurite with a production-style URL, the account name should be the host name in fully qualified domain name such as :10000/container. To use production-style URL with account name in the URL path such as :10000/devstoreaccount1/container, make sure to use the --disableProductStyleUrl parameter when you start Azurite.

If you use host.docker.internal as request Uri host (For example: :10000/devstoreaccount1/container), Azurite gets the account name from the request Uri path. This behavior is true regardless of whether you use the --disableProductStyleUrl parameter when you start Azurite.

Azurite supports read-access geo-redundant replication (RA-GRS). For storage resources, access the secondary location by appending -secondary to the account name. For example, the following address might be used for accessing a blob using the read-only secondary in Azurite: