Forum Replies Created
-
Posts
-
https://os.mbed.com/questions/80116/time_t-is-broken-with-2017-q4-releas-of-/
time_t is now a 64 bit integer, a 32 bit pointer is not going to end well
Ok, that sort of works. Visual Studio needs a reboot after that setting is changed to completely apply the setting and not throw erroneous errors in the output (in msbuild/gcc.targets. Didn’t prevent the build succeeding)
OK, testing linked 5.5 build, the new options are good 🙂
Feedback on new build output window: I like the highlighting in the new “VisualGDB Build” window, it would be good if it could still be echoed to the normal visual studio output/error list windows. In a solution containing cross platform elements having just 1 window to look at (for e.g. solution rebuild) is strongly desired.
cmake will indeed resolve my issues with msbuild, another reason to look forward to it.
I’m having some trouble with the 5.5 installer (5.4 also after testing :/). As soon as the installer hits “Status: Copying new files” it pops up the error “The specified account already exists”. Please advise what can be done to resolve this conflict
EDIT
Resolved by:Â https://support.microsoft.com/en-ca/help/17588/windows-fix-problems-that-block-programs-being-installed-or-removed
^^ Note that several warnings I listed could be added to the command line instead (C/C++ shared), but due to difficulties with static projects + most external libs are C + working in .cpp files makes it easier to only have a minimal set of C warnings
- Interacting with Linux devs who occasionally want to build/debug with their own tools. I still want the msbuild to be the master project, but make files can be used with any environment and as the current standard, they come up a lot. My current solution for building (barely workable) is a script which scrapes the .rsp files into a zip, and a second one which turns those into a series of build commands but it doesn’t help with tooling
- I didn’t expect *all* of GCC options/warnings to be added, but the editing experience for the “additional options…” fields is sub-par compared to say the preprocessor definitions edit window (each option on a new line). For reference, this is my current set of default options for the C++ field:
- -Wno-register -Wno-missing-braces -Wno-psabi -Wformat=2 -Werror=reorder -Werror=format -Werror=format-extra-args -Wshadow -Wnon-virtual-dtor -Wcast-align -Woverloaded-virtual -Wfloat-conversion -Wmisleading-indentation -Wduplicated-cond -Wduplicated-branches -Wlogical-op -Wnull-dereference -Wdouble-promotion -Wconversion -Wstack-usage=256 -Wstrict-aliasing
- -fconserve-stack may be a flag worth adding to the optimisation UI.
- Excited to hear more about this. CMake resolves my main issue with seperated projects in msbuild (public/private include directories, preprocessor defines, …)
cloned bootloader demo, reproduced both issues
- rebuild application -> failed, bootloader.bin missing
- build bootloader, then application -> build passes, map showes bootloader section isn’t just 0xFF / contains code
- Rebuild bootloader, build application -> build passes, map shows bootloader section is all 0xFF / contains no code
As a side note, the first issue (step #1 failing) is not present if
- the bootloader is built in release, and the application in debug (both projects)
- seperate clean/build steps are used (only affects rebuild)
The second issue (no bootloader code after rebuild) I haven’t found a solution past deleting all the files in VisualGDB/<Build>/*. Just deleting the application or temporary file (*.bootldr-o) has no effect
Have been having an identical issue to @JStolle with rebuild deleting the bootloader binary before it can be used
From the diagnostic logs, the bootloader build finishes at line 2278, and then at the start of the firmware project (Line 4045) it records that output file as part of the clean for the second project
1> <GCC PATH>\sysgcc\7.2.0\arm-eabi\bin\arm-eabi-objcopy.exe -O binary ../VisualGDB/Debug/bootloader ../VisualGDB/Debug/bootloader.bin
…
2> Done executing task “CppClean”.
2> Task “WriteLinesToFile”
2> Task Parameter:File=VisualGDB\Debug\firmware.Build.CppClean.log
2> Task Parameter:
2> Lines=
2> <PROJECT>\visualgdb\debug\bootloader.bin
…bootloader.bin file is not mentioned again until the bootloader.props commands are involed
Additionally, the commands in the tutorial “bootloader.props” aren’t complete in a very frustrating way. If the bootloader project is modified for any reason, the bootldr section for the firmware project will be empty (map file shows *(.bootldr) immediately followed by “FILL …”). A manual clean of the binary folder is required before it will work as expected again. This is extremely non-obvious as it appears to work once, and then fail repeatedly with no setup changes
Correction, these views are only available while in a debug session (I’m really blind today…). Any particular reason for this? (disassembly can be quite useful for general analysis)
Apologies, I had the incorrect project selected as startup in VS2019 -.-
While searching for the solution to this, I did however find that in neither version can I find a way to open the general disassembly view without stepping into a libc function (e.g. sprintf) during debugging? This is with an embedded project
Forgot to mention, the resources linked from this page are invaluable in learning how to tweak the mbed build (it could be useful to have to help/reference links in the project properties). I’ve not dealt with mbed-cli directly much before so a few things took a while to work out what I actually needed (still unsure if there’s any facility for overriding compiler flags for a single file/directory, but I only required this on rare occasions so will not miss it enormously).
