Cannot do "mbed new ." again after an error

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
baga_4725781
Level 3
Level 3
10 replies posted 5 replies posted 5 questions asked

A rant: y'all excel in making the process of programming your boards as difficult as possible. ModusToolkit is *way* over engineered and a right pain. I switched to mbed, and it appeared to be much better.

I'm an old fart who started programming in 1976. It was expected that things were going to be difficult because the tools were pretty primitive. I started programming 8080 assembly code on a system with one (count them: one) 8" floppy drive. I've been doing embedded systems longer than most of the cypress dev team has been alive.

However, I now expect professional grade tools that do not get in the way. I want to download the toolkit, compile blinky && get it running. I then want to either change blinky for my purposes, start with a main.c and add to it, or have a good starting example.

I DO NOT WANT TO SPEND MY TIME CHASING DOWN TERRIBLE TOOLKIT PROBLEMS. I need to get stuff done. Between Modus and now mbed, I have wasted at least a week in the last 4 weeks on braindamaged tools.

The "drag the .hex file into E:" is fantastic. One minor complaint: the stinking thin keeps popping up, which changes the focus. Just let it be, folks. I will open it when I am ready.

An example of a good toolset: Arduino. Good examples. (Somewhat bad C, but I quibble.)

However:

1. You must re-run "mbed new ." with every new project, instead of just putting it in one place. If you need to support projects for different boards, then have separate directories for each variation, and an environment variable pointing to each.

2. there is no graceful recovery from an error. I created a separate directory for a project, and ran "mbed new ." I got:

bgangwere@cronus /c/Users/bgangwere/mtw/mbed_ss

$ mbed new .

[mbed] Working path "C:\Users\bgangwere\mtw\mbed_ss" (directory)

[mbed] Program path "C:\Users\bgangwere\mtw\mbed_ss"

[mbed] Creating new program "mbed_ss" (git)

[mbed] Adding library "mbed-os" from "https://github.com/ARMmbed/mbed-os" at branch/tag "latest"

error: Could not fetch origin

[mbed] ERROR: Unable to clone repository (https://github.com/ARMmbed/mbed-os/#latest)

---

bgangwere@cronus /c/Users/bgangwere/mtw/mbed_ss

$ mbed new .

[mbed] Working path "C:\Users\bgangwere\mtw\mbed_ss" (program)

[mbed] ERROR: A program with name "mbed_ss" already exists.

---

NOW I'M STUCK - for no good reason. The "new" script should handle this case.

Git is installed.

I realistically have zero method of debugging this because of your complex python scripts.

3. I built the blinky and it worked. I upgraded to python 3.7. Now I am hosed.

The python upgrade was messy.

(I'm an old fart, so sometimes easily confused because of braindamaged tool installs.

I first tried installing python by downloading the install packages.

This was a mess - and finally realized I should have done a Cygwin install of python.

As a result, when I try to rebuild the blinky, I get this. There are two major issues, which may be related.

A) Assuming the compiler is correct (ARM_GCC), I SHOULD NOT GET ERRORS. This is just sloppy.

B) I have no way to correct the path to python for the message [mbed] ERROR: "C:\Python27\python.exe" returned error.

I'm going to be forced to kludge up a symbolic link to the python.

[mbed] Working path "C:\Users\bgangwere\mtw\mbed-os-example-blinky-baremetal" (program)

[Warning] @,: Compiler version mismatch: Have 6.3.1; expected version >= 9.0.0 and < 10.0.0

Building project mbed-os-example-blinky-baremetal (CY8CKIT_062_WIFI_BT, GCC_ARM)

Scan: mbed-os-example-blinky-baremetal

Using RAM region application_ram in this build.

  Region application_ram: size 0x45800, offset 0x8002000

Link: mbed-os-example-blinky-baremetal

BUILD/CY8CKIT_062_WIFI_BT/GCC_ARM/mbed-os/targets/TARGET_Cypress/TARGET_PSOC6/common/udb-sdio-whd/SDIO_HOST.o: In function `SDIO_IRQ':

C:\Users\bgangwere\mtw\mbed-os-example-blinky-baremetal/.\mbed-os\targets\TARGET_Cypress\TARGET_PSOC6\common\udb-sdio-whd/SDIO_HOST.c:1291: undefined

reference to `cy_rtos_set_semaphore'

C:\Users\bgangwere\mtw\mbed-os-example-blinky-baremetal/.\mbed-os\targets\TARGET_Cypress\TARGET_PSOC6\common\udb-sdio-whd/SDIO_HOST.c:1311: undefined

reference to `cy_rtos_set_semaphore'

BUILD/CY8CKIT_062_WIFI_BT/GCC_ARM/mbed-os/targets/TARGET_Cypress/TARGET_PSOC6/common/udb-sdio-whd/SDIO_HOST.o: In function `SDIO_Free':

C:\Users\bgangwere\mtw\mbed-os-example-blinky-baremetal/.\mbed-os\targets\TARGET_Cypress\TARGET_PSOC6\common\udb-sdio-whd/SDIO_HOST.c:1470: undefined

reference to `cy_rtos_deinit_semaphore'

collect2.exe: error: ld returned 1 exit status

[ERROR] BUILD/CY8CKIT_062_WIFI_BT/GCC_ARM/mbed-os/targets/TARGET_Cypress/TARGET_PSOC6/common/udb-sdio-whd/SDIO_HOST.o: In function `SDIO_IRQ':

C:\Users\bgangwere\mtw\mbed-os-example-blinky-baremetal/.\mbed-os\targets\TARGET_Cypress\TARGET_PSOC6\common\udb-sdio-whd/SDIO_HOST.c:1291: undefined

reference to `cy_rtos_set_semaphore'

C:\Users\bgangwere\mtw\mbed-os-example-blinky-baremetal/.\mbed-os\targets\TARGET_Cypress\TARGET_PSOC6\common\udb-sdio-whd/SDIO_HOST.c:1311: undefined

reference to `cy_rtos_set_semaphore'

BUILD/CY8CKIT_062_WIFI_BT/GCC_ARM/mbed-os/targets/TARGET_Cypress/TARGET_PSOC6/common/udb-sdio-whd/SDIO_HOST.o: In function `SDIO_Free':

C:\Users\bgangwere\mtw\mbed-os-example-blinky-baremetal/.\mbed-os\targets\TARGET_Cypress\TARGET_PSOC6\common\udb-sdio-whd/SDIO_HOST.c:1470: undefined

reference to `cy_rtos_deinit_semaphore'

collect2.exe: error: ld returned 1 exit status


[mbed] ERROR: "C:\Python27\python.exe" returned error.

       Code: 1

       Path: "C:\Users\bgangwere\mtw\mbed-os-example-blinky-baremetal"

       Command: "C:\Python27\python.exe -u C:\Users\bgangwere\mtw\mbed-os-example-blinky-baremetal\mbed-os\tools\make.py -t GCC_ARM -m CY8CKIT_062_WI

FI_BT --source . --build .\BUILD\CY8CKIT_062_WIFI_BT\GCC_ARM"

       Tip: You could retry the last command with "-v" flag for verbose output

---

0 Likes
1 Solution
DheerajK_81
Moderator
Moderator
Moderator
First comment on KBA First comment on blog 5 questions asked

Hello,

Thank you for your feedback. We will evaluate your query and see how we can improve this experience for our users.

For issues you faced with mbed-cli, you will need to report this to ARM Mbed Community since they are the active maintainers for it.

Answering your questions:

1. You must re-run "mbed new ." with every new project, instead of just putting it in one place. If you need to support projects for different boards, then have separate directories for each variation, and an environment variable pointing to each.

Running the command "mbed new ." is going to create a project folder that will have the project name set as the directory the command is run and import the mbed-os library required for developing the project. If your requirement is to have a root Mbed Workspace  directory (for example C:\MbedWorkspace) which houses all your mbed projects, inside the workspace, follow these steps:

(1) Import the Mbed OS library

>> mbed import mbed-os

(2) Configure the same mbed-os library to be used by all the projects

>> mbed config -G MBED_OS_DIR "C:\MbedWorkspace\mbed-os"

(3) For creating new projects, run:

>> mbed new <project1_name>

>> mbed new <project2_name>

(4) To compile any of the projects run:

>> mbed compile -m CY8CKIT_062_WIFI_BT -t GCC_ARM  --source <project1_name> --source mbed-os --build BUILD/<project1_name>

>> mbed compile -m CY8CKIT_062_WIFI_BT -t GCC_ARM  --source <project2_name> --source mbed-os --build BUILD/<project2_name>

Alternately, if we are only focussing on solving the errors:

[mbed] ERROR: A program with name "mbed_ss" already exists.

This occurs because you already have a program file that exists. Check for a file named .mbed. You can delete this file and run "mbed new ." again, it will work correctly.

Additional note:

With mbed-os 6.0 and above, there were major updates to the APIs so the examples you may be importing might have deprecated APIs which no longer work. I recommend that you do the following in case you have everything setup but the compilation stage is failing:

(1) Navigate to mbed-os directory

>> cd mbed-os

(2) Point to an older version of mbed-os that should work properly

>> mbed update mbed-os-5.15.4

(3) Go back to application root directory and compile

>> cd ..

>> mbed compile -t GCC_ARM -m CY8CKIT_062_WIFI_BT

It should now build successfully.

Let me know your observations

Regards,
Dheeraj

View solution in original post

0 Likes
4 Replies
DheerajK_81
Moderator
Moderator
Moderator
First comment on KBA First comment on blog 5 questions asked

Hello,

Thank you for your feedback. We will evaluate your query and see how we can improve this experience for our users.

For issues you faced with mbed-cli, you will need to report this to ARM Mbed Community since they are the active maintainers for it.

Answering your questions:

1. You must re-run "mbed new ." with every new project, instead of just putting it in one place. If you need to support projects for different boards, then have separate directories for each variation, and an environment variable pointing to each.

Running the command "mbed new ." is going to create a project folder that will have the project name set as the directory the command is run and import the mbed-os library required for developing the project. If your requirement is to have a root Mbed Workspace  directory (for example C:\MbedWorkspace) which houses all your mbed projects, inside the workspace, follow these steps:

(1) Import the Mbed OS library

>> mbed import mbed-os

(2) Configure the same mbed-os library to be used by all the projects

>> mbed config -G MBED_OS_DIR "C:\MbedWorkspace\mbed-os"

(3) For creating new projects, run:

>> mbed new <project1_name>

>> mbed new <project2_name>

(4) To compile any of the projects run:

>> mbed compile -m CY8CKIT_062_WIFI_BT -t GCC_ARM  --source <project1_name> --source mbed-os --build BUILD/<project1_name>

>> mbed compile -m CY8CKIT_062_WIFI_BT -t GCC_ARM  --source <project2_name> --source mbed-os --build BUILD/<project2_name>

Alternately, if we are only focussing on solving the errors:

[mbed] ERROR: A program with name "mbed_ss" already exists.

This occurs because you already have a program file that exists. Check for a file named .mbed. You can delete this file and run "mbed new ." again, it will work correctly.

Additional note:

With mbed-os 6.0 and above, there were major updates to the APIs so the examples you may be importing might have deprecated APIs which no longer work. I recommend that you do the following in case you have everything setup but the compilation stage is failing:

(1) Navigate to mbed-os directory

>> cd mbed-os

(2) Point to an older version of mbed-os that should work properly

>> mbed update mbed-os-5.15.4

(3) Go back to application root directory and compile

>> cd ..

>> mbed compile -t GCC_ARM -m CY8CKIT_062_WIFI_BT

It should now build successfully.

Let me know your observations

Regards,
Dheeraj

0 Likes

Thanks for the reply.

1. I was able to hand-build the blinky from other versions I had around. I also did some symbolic link foo to get the right python. I also found (via a colleague) I was using the 32-bit cygwin window when I needed the 64-bit.

2. the need to "mbed new ." for each project. I understand your reply - thanks for being detailed.

However, my point was it should not be necessary to make an entire clone of the common code for each project. The cleanest is to have one copy that can be used by all projects.

The other issue is the source tree created by "mbed new ." is the various target-specific files are sub-trees in the main tree. This is useful only if a developer is using multiple targets. Otherwise, it clutters up the file system.

3. [mbed] ERROR: A program with name "mbed_ss" already exists.

This occurs because you already have a program file that exists. Check for a file named .mbed. You can delete this file and run "mbed new ." again, it will work correctly.

Thank you for the fix. However, this is an example of the process being fragile. The process should be able to recognize the re-run of "mbed new ." on the same directory - the re-run is most likely because of the fail in the first run. Expecting the developer to know they need to delete .mbed and re-run is another example of fragility.

4. I will ponder doing your sequence. I am somewhat hesitant to do it because what I have works, and I am afraid of breaking something. I will try it on a copy of a working source tree.

>> cd mbed-os

>> mbed update mbed-os-5.15.4

I would point out I stated with your source tree from the latest release. I should not have depreciated source.

This points to a larger problem: Your source does not compile cleanly. There are a number of warnings that should have been eliminated before release. I get concerned when I see warnings in a commercial package - it indicates a sloppiness that could be a sign of potential bugs.

5. As I was typing this, the DAPLINK "drive" kept popping up and taking over focus. While it is a great way to download the .hex file, having it popup is getting rather irritating.

Thanks again for the reply.  yours .. bandit

0 Likes

I agree with your opinion. The experience should be easier. The issues and enhancements you have mentioned mostly pertain to Arm Mbed. I strongly recommend you to mention this in the Arm Mbed Community Forum: https://forums.mbed.com/

Cypress is only responsible for the target specific files you see in this directory: mbed-os\targets\TARGET_Cypress. So we won't be able to help in those aspects since we are not the maintainers of the Mbed OS project, we are only a partner.

There are a lot of Mbed OS examples out there that may or may not work. The official ones that are distributed and tested by Cypress can be found here: Cypress Semiconductor Corporation · GitHub

Mbed OS has frequent releases and sometimes a major update is not completely backward compatible and hence things break. It will take time for all the code examples to be updated and hence the warnings that you see and sometimes even compilation errors. Each of the examples has a Readme.md file that explains how the example is used and an mbed-os.lib file that points to a particular commit of mbed-os that works well. Using the example as is, is the best thing to do. Updating to the latest version may not work so well.

Hope you found this useful

Regards,
Dheeraj

0 Likes

I have found the readme.md files to be somewhat useful, but still have "issues".

I will post my rant on the forum. Thanks for the link.

And I will look at the "official" Cypress github. Thanks again.

yours ... bandit

0 Likes