January 3, 2018 at 15:53 #13365
Hi, I’ve just created a new project, importing from CubeMX and I’ve got a conflict.
With Fast Semihosting enabled, I get a multiple definition for _isatty, one in syscalls.c and one in FastSemihosting.cpp
Perhaps I have some things set up incorrectly. It seems there’s been an update, as I don’t remember the option to import directly from STM32CubeMX. And I noticed that, whereas before I was including various frameworks, this time that just doubles up everything as its already coming through on the import.
Thanks for any help,
JoeJanuary 3, 2018 at 19:36 #13370
If you would like to use fast semihosting, you would need to remove other implementations of the low-level I/O functions from the project. The default implementations from the toolchain shipped with VisualGDB are marked as weak, so they will be automatically replaced by the fast semihosting ones (when enabled), however if your project provides different implementations (in syscalls.c?) please try excluding them from the project (if you are using the GNU ARM toolchain, please disable regular semihosting on the first page of VisualGDB Project Properties).January 3, 2018 at 22:54 #13371
Thanks for the reply. I’m not deliberately avoiding the VisualGDB toolchain, and in fact this all worked fine in my last project. I’m just wondering if the new function of importing from STM32CubeMX is doing something strange. I’ve ticked ‘Add necessary library files as reference in the toolchain project configuration file’ in cubemx but the project file seems to be pointing to Cubemx versions (c:\users\joe\stm32cube…) rather than visualgdb.
When I added the stm32f3cube hal it created a lot of conflicts. So it would appear that cubemx is producing references differently than in previous projects? I’ve copied to the cubemx project file from before so have only made minimal changes. Not sure why things are behaving differently. I can only see the new import option as a change from before.January 4, 2018 at 00:49 #13372
I guess using the new import option, the firmware location needs to be specified. But the folder structure for STM32CubeMX (…\Repository\STM32Cube_FW_F3_V1.9.0) is somewhat different to the visualGDB one (…\VisualGDB\EmbeddedBSPs\arm-eabi\com.sysprogs.arm.stm32\STM32F3xxxx\).
So I’m not sure what to put in there.January 5, 2018 at 06:31 #13374
The conflicts between files would likely be caused by VisualGDB referencing its own frameworks (e.g. STM32 HAL). If you are using the latest VisualGDB 5.3 with the new automatic STM32CubeMX importer as described here, it should not happen. If it does, could you please upload the project generated by STM32CubeMX and the project imported by VisualGDB and post a link here so that we could see what is going on?
You can also just remove the references to the VisualGDB version of the HAL via VisualGDB Project Properties -> Embedded Frameworks.January 5, 2018 at 14:31 #13376
Hi, yes that’s what’s happening. I’ll try and upload a bit later.
My temporary solution was to remove the embedded framework references as you said, but then I ran into that problem with the Fast Semihosting framework as it was conflicting with the cubemx refs for _isattyJanuary 5, 2018 at 17:38 #13377
That would be normal if the imported code provides its own I/O functions. The linker usually mentions both source files defining the conflicting function in the error message, so you can simply locate the one coming from CubeMX and remove it from the project.January 7, 2018 at 13:46 #13381
Hi, the problem is that with the new gpdsc importer, it guarantees you’re going to get conflicts. The solution is to remove all the cubemx sources and headers referenced in the generated project, delete the include folder additions in the project settings, and enable the embedded frameworks in visualgdb.
That is more work than it used to be, when using the import from source files, adding the inc folder, and selecting the choice of embedded frameworks.
Attached is an example of an imported project (along with the cubemx base.ioc and base.gpdsc files). The only other thing I did was enable the Fast Semihosting, which gives rise to the clash with _isatty.
I think if the gpdsc importer is going to be useful, it needs to detect and override the sources of the embedded frameworks coming from cubemx. Or is there something that can be put in for the alternative firmware location in cubemx? As I see it, cubemx firmware and visualgdb firmware use different folder structures so I’m not sure what I would put in that field.
Attachments:You must be logged in to view attached files.January 8, 2018 at 03:44 #13385
Thanks for attaching the project. The new STM32CubeMX importer actually does exactly what you are describing – it explicitly removes references to the STM32 HAL installed by VisualGDB so that the project can use the version from STM32CubeMX.
The project you attached doesn’t build because you have both the regular and the advanced semihosting enabled at the same time. Please disable the regular semihosting as shown below:
- This reply was modified 1 week, 4 days ago by support.
Attachments:You must be logged in to view attached files.
You must be logged in to reply to this topic.