ciaaPOSIX_write() stops the system in ciaa_nxp and edu_ciaa_nxp target about firmware_v1 HOT 6 CLOSED

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.

from firmware_v1.

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.

from firmware_v1.

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

from firmware_v1.

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

from firmware_v1.

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.

from firmware_v1.

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

from firmware_v1.