search

ciaa / firmware_v1

Firmware de la CIAA
http://www.proyecto-ciaa.com.ar
126 stars 120 forks source link

ciaaPOSIX_write() stops the system in ciaa_nxp and edu_ciaa_nxp target #455

Closed mabeett closed 7 years ago

mabeett commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

glpuga commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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