Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

STM32 Project only builds Unity #3

Closed
DPastl opened this issue Mar 5, 2021 · 20 comments
Closed

STM32 Project only builds Unity #3

DPastl opened this issue Mar 5, 2021 · 20 comments
Assignees
Labels
good first issue Good for newcomers

Comments

@DPastl
Copy link

DPastl commented Mar 5, 2021

So far as I can tell, importing the STM32 project only seems to grab the Unity project, following the procedures from the previous directory.

What I did (which I think matches the guides) was to:

  1. Grab the build package for STM32F series as linked, version 1.25
  2. Create a directory and clone ubxlib into it
  3. Copy the build package into the same folder, renaming it STM32Cube_FW_F4
  4. Open STM32CubeIde, using the same directory as ubxlib and tools as the workspace. Then import the runner project (only project available)
  5. Click "RUN"

This then fails since Unity isn't installed. Examining the sources, only the Unity running is included in the project as a "main" file.

image

@RobMeades RobMeades self-assigned this Mar 5, 2021
@RobMeades
Copy link
Contributor

Hi there, and thanks for raising the issue. I will try this from scratch myself ASAP but one point I can think of is that the Eclipse workspace is nothing to do with anything described here. For instance, mine is c:\users\rob\eclipse-workspace or some such whereas all my code/builds etc. are in c:\projects\ubxlib; Eclipse workspaces contain its own bizarre metadata and aren't connected with the real world, as far as I can tell. I don't know whether having the workspace in the same place as everything else confuses Eclipse. Certainly would confuse me :-).

Anyway, will get back to you soon.

@DPastl
Copy link
Author

DPastl commented Mar 5, 2021

Thanks Rob, no rush. I was just trying to evaluate if this library would work in my project and found that I couldn't get the firmware build to work.

I'm trying to evaluate if this is suitable for some of the lowest end STM32 MCUs, much smaller than the STM32F series. Do you happen to know the compiled flash and ram size of the application?

@RobMeades
Copy link
Contributor

Yes: approx 60 kbytes flash (plus clib of course), RAM wise it depends what you do with it but definitely less than 40 kbytes heap and we know the worst case test usage fits into a 64 kbytes of an NRF52 with 10 kbytes to spare.

@RobMeades
Copy link
Contributor

@RobMeades
Copy link
Contributor

RobMeades commented Mar 5, 2021

So that you don't have to build that, the output is below, so less flash than I said, and there's a change coming to remove floating point (which is only needed in a few specific places you might not care about) which would remove ~20 kbytes of C library if you don't need it for other reasons yourself. Wise to budget a little room for expansion of course.

    text       data        bss      total filename
       152          8          0        160 u_ble.o
       672         93          0        765 u_ble_cfg.o
       960         55          0       1015 u_ble_data.o
       884        608          0       1492 u_cell.o
      1980        570          0       2550 u_cell_pwr.o
      3204       1320          0       4524 u_cell_cfg.o
      2424        952          0       3376 u_cell_info.o
      9580       3783          0      13363 u_cell_net.o
      3588        318        232       4138 u_cell_sock.o
      2424        165          0       2589 u_cell_sec.o
      1060        512         16       1588 u_cell_sec_c2c.o
       932        371          8       1311 u_cell_private.o
       656          0          8        664 u_network.o
       372          0         16        388 u_network_private_ble.o
       512          0         72        584 u_network_private_cell.o
        30          0          0         30 u_network_private_wifi.o
      4552       1394        636       6582 u_sock.o
       348          0          0        348 u_security.o
      5880        577         12       6469 u_at_client.o
      1960        322          4       2286 u_short_range.o
       672         15          0        687 u_short_range_edm.o
      2500         35        196       2731 u_short_range_edm_stream.o
        56        196          8        260 u_short_range_private.o
       840         15         84        939 u_port_event_queue.o
       180          0          0        180 u_port.o
        34          0          0         34 u_lib.o
         4          0          0          4 u_main.o
     77948      13517       1392      92857 total_when_linked_with_clib.elf

@RobMeades
Copy link
Contributor

...and I'm currently prototyping using this code in a future part that has 128 kbytes program space and 48 kbytes r/w data space.

@DPastl
Copy link
Author

DPastl commented Mar 5, 2021

Hey @RobMeades , wow, thanks for all the information!

That might fit but it could be tight, I'm hoping to fit it in something like 20-30kB flash and only 5kB of RAM, as I'm using the rest for the rest of the application. I'll have to do some testing I think and see where I'm at.

Thanks again and have a great weekend!

@RobMeades
Copy link
Contributor

RobMeades commented Mar 5, 2021

5 kbytes RAM is going to be tight I think, though obviously it depends mostly on your application use-case. We don't try to optimise buffer sizes (e.g. AT buffer is set to 1024 bytes in case you don't happen to have flow control but it doesn't need to be that big, UART buffer is sized for the case where chip to chip security is active but I doubt you need that, don't know whether you need cellular or Wifi or BLE but in the RAM numbers above at least two of the three are assumed to be active etc.) so there will be scope to squeeze.

And of course you could always just takes bits of the code and work it into something of your own.

Nice website by the way :-).

@RobMeades RobMeades added the good first issue Good for newcomers label Mar 6, 2021
@RobMeades
Copy link
Contributor

RobMeades commented Mar 8, 2021

OK, I've tried to recreate this and, in so doing, have realised that the step that is missing from the list you included above is this one, cloning Unity, the unit test framework, to sit beside ubxlib and STM32Cube_FW_F4. Quite why that made the STM32Cube IDE only show you Unity I can't explain but I have seen Eclipse go a bit doolally and merrily re-write the contents of .project file if it finds anything wrong.

EDIT: I realise you may have deliberately left the Unity test framework out in order to do your RAM/flash sizing but the runner build requires the Unity test framework since we use the Unity test framework even to run our examples because that way we can check that the examples work. If all you want is sizing then static_size is a better bet.

Here's my complete step-by-step replication so that you can see exactly what I did:

1 Create a new empty directory c:\test_for_issue_3 and CD to that directory.
2 To obtain the ubxlib code, follow the instructions here https://github.com/u-blox/ubxlib#how-to-use-this-repo:
2.1 Execute git clone https://github.com/u-blox/ubxlib.git:

Cloning into 'ubxlib'...
remote: Enumerating objects: 3250, done.
remote: Counting objects: 100% (3250/3250), done.
remote: Compressing objects: 100% (1165/1165), done.
remote: Total 3250 (delta 1968), reused 3074 (delta 1793), pack-reused 0
Receiving objects: 100% (3250/3250), 3.70 MiB | 357.00 KiB/s, done.
Resolving deltas: 100% (1968/1968), done.
Checking out files: 100% (359/359), done.

2.2. To obtain the sub-modules, CD to the ubxlib sub-directory and execute git submodule update --init --recursive:

Submodule 'port/platform/zephyr/custom_boards' (https://github.com/u-blox/u-blox-sho-OpenCPU) registered for path 'port/platform/zephyr/custom_boards'
Cloning into 'C:/test_for_issue_3/ubxlib/port/platform/zephyr/custom_boards'...
Submodule path 'port/platform/zephyr/custom_boards': checked out '7926c43153edcd5f481e70d3926ad14e44d1bdcd'

Result: I now have c:\test_for_issue_3\ubxlib full of the cloned ubxlib code.

3 To set up the build, follow the instructions here https://github.com/u-blox/ubxlib/blob/master/port/platform/stm32cube/mcu/stm32f4/runner/README.md:
3.1 Download version 1.25.0 of the STM32F4 SDK from https://www.st.com/en/embedded-software/stm32cubef4.html and unblock the .zip file.
3.2 Unzip the 50,005-file directory tree from this into a sub-directory of c:\test_for_issue_3 named STM32Cube_FW_F4, i.e. unzip it and rename the top-level directory from STM32Cube_FW_F4_V1.25.0 to STM32Cube_FW_F4, so c:\test_for_issue_3\STM32Cube_FW_F4 now contains:

Documentation
Drivers
License.md
Middlewares
package.xml
Projects
README.md
Release_Notes.html
Utilities
_htmresc

3.3 To obtain Unity, the unit test environment, CD to c:\test_for_issue_3 and execute git clone https://github.com/ThrowTheSwitch/Unity:

Cloning into 'Unity'...
remote: Enumerating objects: 20, done.
remote: Counting objects: 100% (20/20), done.
remote: Compressing objects: 100% (18/18), done.
remote: Total 5797 (delta 4), reused 7 (delta 2), pack-reused 5777
Receiving objects: 100% (5797/5797), 6.56 MiB | 882.00 KiB/s, done.
Resolving deltas: 100% (3588/3588), done.

Result: I now have c:\test_for_issue_3 with the following three sub-directories:

STM32Cube_FW_F4
ubxlib
Unity

4 Open the STM32Cube IDE and tell it to create a new workspace in C:\test_for_issue_3.
5 Select "Open project from file system", navigate to the directory c:\test_for_issue_3\ubxlib\port\platform\stm32cube\mcu\stm32f4\runner and press "Open" and then "Finish" (without editing any settings):

eclipse_1

6 Select "Project->Build All":

eclipse_2

Result: c:\test_for_issue_3 now contains:

08/03/2021  20:05    <DIR>          .
08/03/2021  20:05    <DIR>          ..
08/03/2021  20:04    <DIR>          .metadata
08/03/2021  20:05    <DIR>          RemoteSystemsTempFiles
08/03/2021  19:38    <DIR>          STM32Cube_FW_F4
08/03/2021  18:54    <DIR>          ubxlib
08/03/2021  19:59    <DIR>          Unity

...and down in the project directory, c:\test_for_issue_3\ubxlib\port\platform\stm32cube\mcu\stm32f4\runner, as well as the stuff that came from the ubxlib repo, there is now the gunk that Eclipse creates:

.settings
Debug
Drivers
Middlewares
Ubxlib
[.cproject]
[.project]
[README.md]

...and in the Debug sub-directory is the build output:

Core
Drivers
makefile
Middlewares
objects.list
objects.mk
runner.bin
runner.elf
runner.list
runner.map
sources.mk
Ubxlib

@gwchin14
Copy link

gwchin14 commented May 6, 2021

Hi, Rob,

I have followed your instructions but facing 22 errors in my attempt to build the project, please see the screenshot below and "BuildLog.txt" attachment. It seems that there is problem in the "Ubxlib -> U-blox -> Port -> u_port_uart.c"

BuildLog.txt
STM32

@RobMeades
Copy link
Contributor

Hi there. It looks like the build is unable to find the definitions of some of the LL_ functions which are provided by the ST SDK. Taking a specific example, LL_USART_DeInit() should be defined in the ST SDK file Drivers/STM32F4xx_HAL_Driver/Inc/stm32f4xx_ll_usart.h and implemented in the ST SDK file Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_ll_usart.c.

Can you tell me which version of the ST SDK you are using? As indicated in the README.md we tested with version 1.25.0. Can you grep the ST SDK directory for the function LL_USART_DeInit() to ensure that it is really there?

@RobMeades
Copy link
Contributor

If the answers to the above are "1.25.0" and "yes", then can you post the .project and .cproject files from your build here? Maybe they have become corrupted somehow?

@gwchin14
Copy link

gwchin14 commented May 6, 2021

Hi, Rob,
Yes, I am using version 1.25.0 download from https://www.st.com/en/embedded-software/stm32cubef4.html
The "stm32f4xx_II_usart.c" has included the library file "stm32f4xx_II_usart.h", but the this library file seems to be in the wrong folder, please see the screenshots below:
stm32f4xx_II_usart
stm32f4xx_II_usart_h
Inc

@gwchin14
Copy link

gwchin14 commented May 6, 2021

Hi, Rob,

Below is the .project file, I am not sure where is the .cproject file, perhaps you can point to me where it is, thanks.

project.zip

@RobMeades
Copy link
Contributor

RobMeades commented May 6, 2021

Ah, no, don't look at the folders in the Eclipse view, they are an Eclipse "fantasy view" and bear no relationship with the real world at all. Please grep for the function LL_USART_DeInit in the ST SDK folder on your hard disk (i.e. in C:\test_for_issue_3\STM32Cube_FW_F4).

Not being able to find the .cproject file might point to a problem: it must be present in the same directory as the .project file, see my version of the build here:

image

If I download a fresh copy of the ST SDK version 1.25.0 from ST and do that search I find the declaration of the function LL_USART_DeInit() in the following directory within the .zip file:

en.stm32cubef4_v1-25-0.zip\STM32Cube_FW_F4_V1.25.0\Drivers\STM32F4xx_HAL_Driver\Inc

When I do the build following the above procedure, the line where u_port_uart.c is built is logged as:

arm-none-eabi-gcc "C:/test_for_issue_3/ubxlib/port/platform/stm32cube/src/u_port_uart.c" -mcpu=cortex-m4 -std=gnu11 -g3 -DUSE_HAL_DRIVER -DUSE_FULL_LL_DRIVER -DSTM32F437xx -DDEBUG -c -IC:/test_for_issue_3/ubxlib/port/platform/stm32cube/app -IC:/test_for_issue_3/ubxlib/ble/api -IC:/test_for_issue_3/ubxlib/ble/src -IC:/test_for_issue_3/ubxlib/ble/test -IC:/test_for_issue_3/ubxlib/cfg -IC:/test_for_issue_3/ubxlib/common/error/api -IC:/test_for_issue_3/ubxlib/common/network/api -IC:/test_for_issue_3/ubxlib/common/network/src -IC:/test_for_issue_3/ubxlib/common/network/test -IC:/test_for_issue_3/ubxlib/common/sock/api -IC:/test_for_issue_3/ubxlib/common/sock/test -IC:/test_for_issue_3/ubxlib/common/security/api -IC:/test_for_issue_3/ubxlib/common/security/test -IC:/test_for_issue_3/ubxlib/common/at_client/api -IC:/test_for_issue_3/ubxlib/common/short_range/api -IC:/test_for_issue_3/ubxlib/common/short_range/src -IC:/test_for_issue_3/ubxlib/common/short_range/test -IC:/test_for_issue_3/ubxlib/cell/api -IC:/test_for_issue_3/ubxlib/cell/src -IC:/test_for_issue_3/ubxlib/cell/test -IC:/test_for_issue_3/ubxlib/common/network/api -IC:/test_for_issue_3/ubxlib/common/security/api -IC:/test_for_issue_3/ubxlib/port/api -IC:/test_for_issue_3/ubxlib/port/platform/common/event_queue -IC:/test_for_issue_3/ubxlib/port/platform/stm32cube/inc -IC:/test_for_issue_3/ubxlib/port/platform/stm32cube/src -IC:/test_for_issue_3/ubxlib/port/platform/stm32cube/app -IC:/test_for_issue_3/ubxlib/port/platform/stm32cube/mcu/stm32f4/cfg -IC:/test_for_issue_3/ubxlib/port/platform/common/runner -IC:/test_for_issue_3/ubxlib/port/platform/common/heap_check -IC:/test_for_issue_3/Unity/src -IC:/test_for_issue_3/STM32Cube_FW_F4/Middlewares/Third_Party/FreeRTOS/Source/include -IC:/test_for_issue_3/STM32Cube_FW_F4/Middlewares/Third_Party/FreeRTOS/Source/CMSIS_RTOS -IC:/test_for_issue_3/STM32Cube_FW_F4/Middlewares/Third_Party/FreeRTOS/Source/portable/GCC/ARM_CM4F -IC:/test_for_issue_3/STM32Cube_FW_F4/Middlewares/Third_Party/mbedTLS/include -IC:/test_for_issue_3/STM32Cube_FW_F4/Drivers/STM32F4xx_HAL_Driver/Inc -IC:/test_for_issue_3/STM32Cube_FW_F4/Drivers/STM32F4xx_HAL_Driver/Inc/Legacy -IC:/test_for_issue_3/STM32Cube_FW_F4/Drivers/CMSIS/Include -IC:/test_for_issue_3/STM32Cube_FW_F4/Drivers/CMSIS/Device/ST/STM32F4xx/Include -O0 -ffunction-sections -fdata-sections -Wall "-DU_CFG_TEST_CELL_MODULE_TYPE=U_CELL_MODULE_TYPE_SARA_U201" "-DU_CFG_APP_FILTER=cellCfg" "-DU_CFG_TEST_PIN_UART_A_CTS=-1" "-DU_CFG_TEST_PIN_UART_A_RTS=-1" "-DU_CFG_TEST_PIN_UART_B_RXD=0x17" "-DU_CFG_TEST_PIN_UART_B_TXD=0x16" "-DU_CELL_TEST_CFG_EUTRAN_APN=tsiot" "-DU_CFG_APP_CELL_UART=2" "-DU_CFG_APP_PIN_CELL_RXD=0x36" "-DU_CFG_APP_PIN_CELL_TXD=0x35" "-DU_CFG_APP_PIN_CELL_RTS=0x34" "-DU_CFG_APP_PIN_CELL_CTS=0x33" "-DU_CFG_TEST_UART_Bx=1" "-DU_CFG_TEST_PIN_A=-1" "-DU_CFG_TEST_PIN_B=-1" "-DU_CFG_TEST_PIN_C=-1" "-DU_CELL_TEST_CFG_APNx=tsiot" "-DU_CELL_TEST_CFG_BANDMASK1=0x0000000000080084ULL" -fstack-usage -MMD -MP -MF"Ubxlib/U-Blox/Port/u_port_uart.d" -MT"Ubxlib/U-Blox/Port/u_port_uart.o" --specs=nano.specs -mfpu=fpv4-sp-d16 -mfloat-abi=hard -mthumb -o "Ubxlib/U-Blox/Port/u_port_uart.o"

You can see that in every case all include paths (the -I lines) are absolute, so the file in question is found from the entry -IC:/test_for_issue_3/STM32Cube_FW_F4/Drivers/STM32F4xx_HAL_Driver/Inc

If I look in the BuildLog.txt file that you attached above, the equivalent line for your build is:

arm-none-eabi-gcc "C:/test_for_issue_3/ubxlib/port/platform/stm32cube/src/u_port_uart.c" -mcpu=cortex-m4 -std=gnu11 -g3 -DUSE_HAL_DRIVER -DSTM32F437xx -DDEBUG -c -IC:/test_for_issue_3/ubxlib/port/platform/stm32cube/app -IC:/test_for_issue_3/ubxlib/ble/api -IC:/test_for_issue_3/ubxlib/ble/src -IC:/test_for_issue_3/ubxlib/ble/test -IC:/test_for_issue_3/ubxlib/cfg -IC:/test_for_issue_3/ubxlib/common/error/api -IC:/test_for_issue_3/ubxlib/common/network/api -IC:/test_for_issue_3/ubxlib/common/network/src -IC:/test_for_issue_3/ubxlib/common/network/test -IC:/test_for_issue_3/ubxlib/common/sock/api -IC:/test_for_issue_3/ubxlib/common/sock/test -IC:/test_for_issue_3/ubxlib/common/security/api -IC:/test_for_issue_3/ubxlib/common/security/test -IC:/test_for_issue_3/ubxlib/common/at_client/api -IC:/test_for_issue_3/ubxlib/common/short_range/api -IC:/test_for_issue_3/ubxlib/common/short_range/src -IC:/test_for_issue_3/ubxlib/common/short_range/test -IC:/test_for_issue_3/ubxlib/common/mqtt_client/api -IC:/test_for_issue_3/ubxlib/cell/api -IC:/test_for_issue_3/ubxlib/cell/src -IC:/test_for_issue_3/ubxlib/cell/test -IC:/test_for_issue_3/ubxlib/port/api -IC:/test_for_issue_3/ubxlib/port/clib -IC:/test_for_issue_3/ubxlib/port/platform/common/event_queue -IC:/test_for_issue_3/ubxlib/port/platform/stm32cube/inc -IC:/test_for_issue_3/ubxlib/port/platform/stm32cube/src -IC:/test_for_issue_3/ubxlib/port/platform/stm32cube/app -IC:/test_for_issue_3/ubxlib/port/platform/stm32cube/mcu/stm32f4/cfg -IC:/test_for_issue_3/ubxlib/port/platform/common/runner -IC:/test_for_issue_3/ubxlib/port/platform/common/heap_check -IC:/test_for_issue_3/Unity/src -IC:/test_for_issue_3/STM32Cube_FW_F4/Middlewares/Third_Party/FreeRTOS/Source/include -IC:/test_for_issue_3/STM32Cube_FW_F4/Middlewares/Third_Party/FreeRTOS/Source/CMSIS_RTOS -IC:/test_for_issue_3/STM32Cube_FW_F4/Middlewares/Third_Party/FreeRTOS/Source/portable/GCC/ARM_CM4F -IC:/test_for_issue_3/STM32Cube_FW_F4/Middlewares/Third_Party/mbedTLS/include -IC:/test_for_issue_3/STM32Cube_FW_F4/Drivers/STM32F4xx_HAL_Driver/Inc -IC:/test_for_issue_3/STM32Cube_FW_F4/Drivers/STM32F4xx_HAL_Driver/Inc/Legacy -IC:/test_for_issue_3/STM32Cube_FW_F4/Drivers/CMSIS/Include -IC:/test_for_issue_3/STM32Cube_FW_F4/Drivers/CMSIS/Device/ST/STM32F4xx/Include -I../Core/Inc -I../Drivers/STM32F4xx_HAL_Driver/Inc -I../Drivers/STM32F4xx_HAL_Driver/Inc/Legacy -I../Drivers/CMSIS/Device/ST/STM32F4xx/Include -I../Drivers/CMSIS/Include -O0 -ffunction-sections -fdata-sections -Wall -fstack-usage -MMD -MP -MF"Ubxlib/U-Blox/Port/u_port_uart.d" -MT"Ubxlib/U-Blox/Port/u_port_uart.o" --specs=nano.specs -mfpu=fpv4-sp-d16 -mfloat-abi=hard -mthumb -o "Ubxlib/U-Blox/Port/u_port_uart.o"

If you look towards the end you will see -I../Drivers/STM32F4xx_HAL_Driver/Inc: this is incorrect, for some reason Eclipse has given the compiler a relative path for a few of the ST driver files which will not work and is not what our build metadata (in the .project and .cproject files) tells it to do, it must always have the full path.

I guess this might happen if .cproject has gone missing. As I comment at the end of the README.md in the stm32f4 directory, I have seen the Eclipse IDE fiddle with the contents of the .project and .cproject files on occasion, maybe it decided to entirely vapourise the .cproject file in your case?

To try again, I suggest that you:

  • close Eclipse,
  • delete the Eclipse workspace (I guess delete the C:\test_for_issue_3\.metadata and C:\test_for_issue_3\RemoteSystemsTempFiles directories),
  • reinstate the .cproject file, in the same directory as the .project file, from the repo,
  • delete everything in the C:\test_for_issue_3\ubxlib\port\platform\stm32cube\mcu\stm32f4\runner directory except the .cproject, .project and README.md files (i.e. delete everything that the Eclipse IDE created).
  • continue from step 4 in the procedure above.

Let me know if that makes things behave any better.

@RobMeades
Copy link
Contributor

FYI, just to be sure that there are no problems, I have repeated the procedure with the very latest ubxlib and a freshly downloaded STM32F4 SDK version 1.25.0. The build output is attached.

So it is possible for it to work, we just have to find out what why the STM32Cube IDE (AKA Eclipse) is doing strange things in your case.

BuildLogRob.txt

@gwchin14
Copy link

gwchin14 commented May 8, 2021

Hi, Rob,

I can locate the .project and .cproject files now. Please see attachments "runner.zip". I have followed your advice as follows but the build project errors occur.

runner.zip

  • close Eclipse,
  • delete the Eclipse workspace (I guess delete the C:\test_for_issue_3.metadata and C:\test_for_issue_3\RemoteSystemsTempFiles directories),
  • reinstate the .cproject file, in the same directory as the .project file, from the repo,
  • delete everything in the C:\test_for_issue_3\ubxlib\port\platform\stm32cube\mcu\stm32f4\runner directory except the .cproject, .project and README.md files (i.e. delete everything that the Eclipse IDE created).
  • continue from step 4 in the procedure above.

@RobMeades
Copy link
Contributor

RobMeades commented May 8, 2021

This is really weird. If I take the.cproject and .project files you have attached above and diff them with the .cproject and .project files from the ubxlib repo they are quite different. In particular the .cproject file is missing the vital compilation flag USE_FULL_LL_DRIVER, which has always been present in the ubxlib version of the .cproject file as the code will never compile without it. The .cproject file also has inserted into it the relative directories I mentioned above (the ones that will never work), see some screenshots of the diff below.

diff1
diff2

So somehow something has modified the .cproject and .project files we provide and hence the build no longer works. I suggest you try the following:

  • close Eclipse,
  • delete the Eclipse workspace (I guess delete the C:\test_for_issue_3.metadata and C:\test_for_issue_3\RemoteSystemsTempFiles directories),
  • delete everything in the C:\test_for_issue_3\ubxlib\port\platform\stm32cube\mcu\stm32f4\runner directory,
  • reinstate the contents of the C:\test_for_issue_3\ubxlib\port\platform\stm32cube\mcu\stm32f4\runner directory, i.e. the .cproject file, the .project file and the README.md file, with versions taken directly from the ubxlib repo (at the same commit as all of your other files of course),
  • ALSO save another copy of these files somewhere on your hard disk so that you are sure you have an unmodified version of them,
  • continue from step 4 in the procedure above,
  • if the errors still occur, diff the versions of the .cproject and .project that you saved elsewhere on your hard disk with the versions in the C:\test_for_issue_3\ubxlib\port\platform\stm32cube\mcu\stm32f4\runner directory to make sure that they have not been modified by Eclipse.

Let me know how you get on.

@gwchin14
Copy link

Hi, Rob,

My build is successful now. I realize I have made a mistake in step #5, whereby after I launch STM32CubeIDE and lanuch the workplace "C:\test_for_issue_3", I choose "Start a new project" instead of select "Open project from file system"...". My fault.

Thanks for all the help and sorry for troubling you.
Successful

@RobMeades
Copy link
Contributor

That's excellent news, many thanks for letting me know and no trouble at all, glad to make sure you are working.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

3 participants