[PR] ciaa_nxp: blinking_echo example does not build about firmware_v1 HOT 9 CLOSED

The rtos submodule reference on the main repository was not updated after the latest batch of merges to the Firmeware.rtos repository. My fault, since I forgot to mention the need to do that when writing the merge request for the changes.

The rtos submodules in the current Firmware repository master needs to be updated to point to the current master of the Firmware.rtos repository.

For the time being, stepping into the modules/rtos folder and executing "git checkout master" restores the build process. Can you confirm this works for you, @mabeett ?

from firmware_v1.

PR open at rtos module repo: ciaa/firmware.modules.rtos#41

from firmware_v1.

The rtos submodules in the current Firmware repository master needs to be updated to point to the current master of the Firmware.rtos repository.

For the time being, stepping into the modules/rtos folder and executing "git checkout master" restores the build process. Can you confirm this works for you, @mabeett ?

Yes, checking out modules/rtos in master each example builds correctly[0]

[0] Disclaimer: I did not test the expected behavior for each example with the board.

from firmware_v1.

@mabeett If you agree, this issue should be renamed to "rtos submodules needs updating to current Firmware.rtos master." or something of that kind. I think only you can do that.

from firmware_v1.

IMO, the issue should remain as is and a new issue «rtos submodules needs updating to current Firmware.rtos master.» should be open.
When the new issue would be solved, this one should be closed too.
I mean this because the root cause es the submodule update, but this is not the issue itself.

Anyway, an administrator also may redefine the sbject an status of this issue.

from firmware_v1.

mmm...
Look at the current master, the problem persists for cortexM0 Os_Internal_Arch_Cfg.c.php

from firmware_v1.

IMO, the issue should remain as is and a new issue «rtos submodules needs updating to current Firmware.rtos master.» should be open. When the new issue would be solved, this one should be closed too. I mean this because the root cause es the submodule update, but this is not the issue itself.

Ok, agree. Let's do that.

mmm... Look at the current master, the problem persists for cortexM0 Os_Internal_Arch_Cfg.c.php

I've never compiled the firmware for the CortexM0 so I'm not sure what error are you seeing, but there is a mistake in the code line you linked:

#include "Os_Internal.h"
#if (CPU == lpc43xx)
/* THIS IS A DIRTY WORKAROUND :( ciaa/Firmware#309*/
#undef FALSE
#undef TRUE
#include "chip.h"
#endif

lpc43xx is not a CPU, but a CPUTYPE. This is something was was corrected on the M4 code when merging the SPARC/picoCIAA code, but seems to have lingered on the M0 code. This code used to work because both "lpc43xx" and "lpc4337" had the same value, but I after the most recent platform additions that's no longer the case.

Try replacing "#if (CPU == lpc43xx)" with "#if (CPUTYPE == lpc43xx)" and see if that fixes the problem you are bumping into.

from firmware_v1.

Try replacing "#if (CPU == lpc43xx)" with "#if (CPUTYPE == lpc43xx)" and see if that fixes the problem you are bumping into.

Yes, this solves the problem.
I do not know in detail the system's file organization, but I understand that the workaround should be applied in the same way for cotexM0 and cortexM4.
I mean #if (CPUTYPE == lpc43xx) or #if (CPU == lpc4337) in
gen/src/cortexM0/Os_Internal_Arch_Cfg.c.php
and
gen/src/cortexM4/Os_Internal_Arch_Cfg.c.php

from firmware_v1.

I do not know in detail the system's file organization, bu I understand that the workaround should be applied in the same way for cotexM0 and cortexM4. I mean #if (CPUTYPE == lpc43xx) or #if (CPU == lpc4337) in gen/src/cortexM0/Os_Internal_Arch_Cfg.c.php and gen/src/cortexM4/Os_Internal_Arch_Cfg.c.php

This is already fixed for cortexM4 in the current master of Firmware.rtos.

I'll create an issue for this.

from firmware_v1.