CPU/CPUTYPE mixup in rtos generator code

[glpuga]

There's an error in Os_Internal_Arch_Cfg.c.php#L55 of the cortexM0 generator file in the rtos submodule:

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

There "#if (CPU == lpc43xx)" should be "#if (CPUTYPE == lpc43xx)".

This used to work out of pure chance because the values of the macros lpc43xx and lpc4337 had the same value, but this stopped being true after pull requests #461, #462 and #463 added new platforms.

[mabeett]

Is there any new regarding this issue?
I am searching for rtos module upgrade in order to get information of #457

[glpuga]

I created a pull request (ciaa/firmware.modules.rtos#42) on the firmware.modules.rtos repository to address this. #465 can also be solved right after the merge; left a reminder about that on the description of the PR.

Regarding #457 , you might want to check a branch I've working during the holidays. It's rework of FreeRTOS CortexM4 context switching interface to address issue #458 , which I think might be related to #453, #456 , #457 and other similar heavy-load system hang-ups.

I'm pretty confident the current version will be my PR proposal ("make rtostest" runs succesfully, user applications should too), but I kept it on hold for the last few days while I was working on a similar modification for CortexM0 on another branch; I also planned to to run a few tests on other non-Cortex platforms to make sure I didn't mess with the build process.

If you want to check this, the code is in https://github.com/glpuga/firmware.modules.rtos , branch features/cortexM4contextswitching . Feedback is welcomed.

[mabeett]

Great!!!!
I may test [0] your code branch. !!! I will do it as soon as possible and I will give you feedback.
I can test with a ciaa-nxp with 2 accessible UARTs. I have files and human elementary methods for testing. Unfortunately I don't have the time which I would like have.

Thanks again.

[0](test as manual test with the board)

[mabeett]

If you want to check this, the code is in https://github.com/glpuga/firmware.modules.rtos , branch features/cortexM4contextswitching .
Feedback is welcomed.

Unfortunately the bug related with two UARTs receiving information persists =(

The test program that I used now is available as repository:
https://github.com/mabeett/test-uart-osek-ciaa

This test program does not uses posix or other wrappers in order to isolate the scheduler change context problem. The project may be used in ciaa-nxp or edu-ciaa-nxp (this one with an additional RS232/FTDI adapter).

Please make me know if you need additional information.