Hello,
Since few hours I'm struggling with compilation error of C++ project based on RT1051 uC. During my investigation I found that those two defines from fsl_clock.h are causing problems:
CCM_TUPLE and CCM_ANALOG_TUPLE
I'm using GNU Arm Embedded Toolchain Version 8-2018-q4-major and CMake, compilator spits those errors:
../bsp/drivers/fsl_clock.h:90:110: error: dereferencing a null pointer in '*0'
#define CCM_ANALOG_TUPLE(reg, shift) ((((uint32_t)(&((CCM_ANALOG_Type *)0U)->reg) & 0xFFFU) << 16U) | (shift))
../bsp/drivers/fsl_clock.h:90:110: error: enumerator value for 'kCLOCK_PllUsb2' is not an integer constant
#define CCM_ANALOG_TUPLE(reg, shift) ((((uint32_t)(&((CCM_ANALOG_Type *)0U)->reg) & 0xFFFU) << 16U) | (shift))../bsp/drivers/fsl_clock.h:594:34: error: expression '0->CCM_Type::CCSR' has side-effects
((((uint32_t)(&((CCM_Type *)0U)->reg)) & 0xFFU) | ((shift) << 8U) | ((((mask) >> (shift)) & 0x1FFFU) << 13U) | \
((busyShift) << 26U))
It looks like g++ compiler is having some difficulties with compiling those macros.
If I won't include "fsl_clock.h" compilation is working. There is no such problem when using gcc compiler.
Any ideas how to fix this issue ? I would be very grateful.
Best Regards
Mateusz Piesta
This issue can be seen here
Hi Kerry,
I've forgotten to mention that I've already tried MCUXpresso. C++ project generated by MCUXpresso is working flawlessly. I believe this is due to different version(probably older) of arm-gcc compiler. I didn't have any issues with this header using older versions of g++ compiler using custom CMake project.
Fortunately I was able to fix this issue. I had to modify those two macros, I used compiler built-in "offsetof" function to calculate structure offsets.
After this modification my project is compiling fine without any problems.
Maybe you should consider upgrading this defines ? This error was easily reproduced on different machines and under different OSes(Windows 10/7, ArchLinux).
Best regards
Mateusz Piesta
Hi I am facing the same issue. I created a new C++ project and when I try to build I am getting the same errors as yours. The two macros in fsl_clock.h are creating problems. I am a beginner in embedded programming so Can you please detail out the method to fix this problem? kerryzhou barrett.lowe@etcconnect.com mateuszpiesta
Hi Anirudhan,
just to doublecheck, what SDK version do you use? I checked with the MCUXpresso SDK team and the problem with the macros should be resolved in SDK v2.6.0.
Regards,
Lukas
Hi Lukas,
I am working on the EVK-MiMXRT1050 board and the latest version of SDK for that board is 2.3. We are planning to move to the EVKB-MiMXRT1050 board which has the updated SDK 2.6.
Thanks a lot for your reply mateuszpiesta barrett.lowe@etcconnect.com. I have made the changes as Mateusz said, and it worked for me.
For me, I just replaced the macros with the ones listed above or in the article that I linked. Kind of a hack but it worked...
Hi Anidudhan,
As I mentioned replace those two macros with :
Also don't forget to add above those two defines:
After those modifications project should compile. If you have any further questions/problems please let me know.
I wonder why this was not included into the new SDK release. It is clear that newer versions of g++ have problems with old C style macros.
I just want to add that it's been a while since I've made those changes and to this day everything seems to work as expected. I haven't encountered any problems so far.
Have a great day !
Mateusz Piesta
Hi Mateusz Piesta,
Thanks a lot for your updated information.
After you modify it, do you also test the project function? Whether it works OK or not on your side?
About your modification for C++, I will record it, thank you!
Have a great day,
Kerry
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Hi Kerry,
We are using RT1050 in quite big and complex project which uses wide range of peripherals. After those changes everything seems to work as usual (we are in middle of converting some project modules to use C++ instead of C). Hence I believe it is pretty safe to say that those changes didn't break anything :smileyhappy:
Best regards
Mateusz Piesta
Hi Mateusz Piesta,
Thanks a lot for your contribution!
Have a great day,
Kerry
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Hi Mateusz Piesta,
Actually, CCM_TUPLE and CCM_ANALOG_TUPLE just the simple shift and the or calculation.
So, it should still in the compiler side.
Do you mind to try the MCUXpresso IDE, whether it also have problems on your side.
If after you tried the MCUXpresso IDE, it also have problems, please kindly let me know.
Have a great day,
Kerry
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------