ciaaPOSIX_write() stops the system in ciaa_nxp and edu_ciaa_nxp target

[mabeett]

If the user uses ciaaPOSIX_write() the system will stop with no clear cause.

A quick way for trigger this bug is just using ciaaPOSIX_write() in an infinte loop, but may be used carefully and anyway will stop.

blinking_write.tar.gz is a test app based on blinking_exho example with ciaaPOSIX_write in an infinite loop.

Applying the patches of #453 the test app works with no freeze.

[mabeett]

I have been working in this issue (and #453) with no advance.
@glpuga do you have a a target different than ciaa-nxp/edu-ciaa-nxp? Would you mind test and deploy this issue and #453 in your target if you have one?
Tanks

[mabeett]

For triggering the bug the user has to send data via RS-232 port.

[glpuga]

I'm afraid I don't have access to a target where your test program can be run as is, since the LEON3 port I worked on does not currently sport a DIO driver, and therefore I would not have a way to tell that the program died through a led.

I may try running the write version without the DIO, checking the alive status through the UART, but it may take some time since I haven't been working on this for some time now and I don't have a hardware target currently available.

[glpuga]

I must also warn you that at most I can confirm that the problem you see seems to manifest itself on my target too.

I cannot deploy your patches, though, and not only for the reasons I already stated on #453 but because I don't have any kind of administrative authority over the CIAA Firmware repository.

[mabeett]

I may try running the write version without the DIO, checking the alive status through the UART, but it may take some time since I haven't been working on this for some time now and I don't have a hardware target currently available.

@glpuga There is no problem, I may prepare an application without write over DIO, and using direct register setting for digital output setting (anyway is just setting in a register). As far I understand, the write over DIO is not part of a problem.

The application must have 2 FULL preemptive tasks with different priorities (being NON preemptive with Schedule(); calls the bug does not appears). In the example PeriodicTask blinking started by alarm and SerialEchoTask with a flooding write via ciaaPOSIX_write().

For blinking without write I may prepare the blinking with macros to LPC driver, you should adapt this to your target.

I am just searching for triggering the bug in an architecture different than lpc, so on this way I could think more in the OS than the LPC's drivers/wrappers.

Make know if preparing a test app with UART via ciaaPOSIX_write() but not DIO via ciaaPOSIX_write() is possible in your scenario and I will make the app triggering the bug for your LEON3. I cannot prepare it intermediately so there will be no problem if you take tour time.

[mabeett]

The cause of this problem is #457, as the tests indicated in the mailing list says .