random uart.write oserror 116

[EasyRider]

Thank You pythoncoder,

Appreciate your assistance.

I think Dave is right about the possible issue with oserror 116. I will run the boards as stand alone for a while to see what happens longer term.

Haven't looked much further into WDT, sort of assumed that the library function was applicable for pyboard.
Anyway, will be playing with WDT in the next few days and will try your code.

Regards
John

[folke]

Hi all,

I too have problem with getting occasional oserror 116 when doing simple uart writes. In my case it's on pyboard v1.0 and the two latest firmwares 1.5.1 and 1.5.2. I have caught some occasions on a logic analyzer and have realized that while sending string at 9600 baud (no handshaking) there are some odd behavior in the uart.write() function. I have surrounded the write function with a setting and clearing of a Pin ("Dbg" in the trace) and can see that the function call gets stuck at several occasions even thou it has only sent a few chars, and sometimes there are long pauses between groups of 3 chars sent (should have been one 24 chars string). I can se examples of complete string sent (on the physical wire), but program still being stuck in the uart.write() function.

My application uses a UART to send and receive strings of data (with 1–≈24 chars each, in total 100's of chars) to/from a 1wire module with serial interface at 9600 baud with no handshaking repeated in 10 s intervals. The 1wire module does the actual 1wire signalling. So the program has no other I/O than one UART (no SD reads or writes, no WD, but it also calls time.localtime()). Often the execution terminates in oserror 116, but I got the feeling(?) it also just can hang inside the uart.write()-function. I have found that when the program has a problem, it doesn't reach the dbg(0) statement immediately following the uart.write() function, or sometimes only after a long delay. This is clearly visible in the logicanalyser. I have some saved captures, but I guess I can only show some examples of them here as pictures. The captures contains a lot of details, but space is limited here, so if there is an interest, I can show more.

Sometimes the program can run for a long time (30 mins) and sometimes i stops/hangs after a couple of secs.

I first tested the program on WiPy (1.5.2) and that worked for without problem for a day or two.

My thinking is that it might have something to do with recent changes in DMA, IRQ, priorities…??

Regards
Folke

[dhylands]

There are only a few things that should affect the timing of the uart writes.

If you're writing individual characters, then it's conceivable that a gc is happening (it would really depend on the code). If you do a write of a buffer containing 3 characters, then the only thing that should interrupt it are interrupts. The primary source of interrupts that take any amount of time is from USB, and in particular related to USB Mass Storage. If you have USB Mass Storage enabled and are connected to the PC via USB, then the host can cause reads/writes to the sdcard on the pyboard (even though you're not transferring files, there are lots of reasons why this might happen).

Currently writing of uart chars is done in the main loop. receiving uart chars is done in an IRQ handler. If we used IRQ or DMA for the writing portion, then the spacing between the characters would be really small, but there could still be a gap between the last character and toggling of the Dbg line.

[folke]

Thank you Dave,

You give clear facts as usual, and I realize now I have some homework to do. Yes, USB mass storage was enabled and maybe Spotlight is playing some tricks on the SD card, that I didn't think about. So an easy test is to disconnect the USB to the Mac and see if problem disappears. I'll be back when done.

The call to uart.write() is always done once for the complete string in one piece. So in the case shown in the pictures, the 24 chars were sent as one call.

Regards,
Folke

[pythoncoder]

To clarify, in my ~46 hour run I had USB mass storage disabled.

[folke]

Hi again,
Yes, Spotlight in Mac OS X is indexing the SD card (which in my case contains ≈100 files). These accesses clearly disturbs the UART Tx (and also Rx), see the second picture in my first post, where the blue Dbg trace shows that it nearly takes 1s to send the 24 chars because they get split up into 5 chunks due to the USB traffic. This is just on the border of the default timeout (1s). I first thought: easily fixed and raised the timeout, but ALAS the uart.write() function seems to have a FIXED timeout of 1s independent of the timeout parameter! (The uart.read() is influenced by it).

To improve the situation, I can disable spotlight from indexing the SD card. But there are still some occasional accesses to it from the OS. So disabling Spotlight indexing does not compleltely solve my problem. I still can get OS err 116 if I send a lot of long strings with uart.write() at the same time as the USB have some transmission. (I have checked it on the logic analyzer).

SUGGESTION: Let uart.write() have it's own timeout or possible the same as uart.read(), the important thing is that it's possible to set the timeout to a longer time than 1s when needed. I should mention that uart.read() also can cause timeout in my program, but since the timeout time is controlled by the timeout parameter, this is just a matter of adjusting the parameter.

[pythoncoder]

In my experience the Pyboard works best with USB access to USB mass storage devices disabled. I use rshell https://github.com/dhylands/rshell.git to manage the filesystems on the flash and SD card (where fitted). Aside from serial port issues it avoids file corruption problems: I gather there is a fundamental design issue with the USB mass storage protocol. This causes problems with PC and Pyboard attempting to access the filesystem concurrently.

[EasyRider]

I have also been able to trace my earlier error to USB access and have been able to reproduce it.

On another uart issue, not absolutely sure yet if it may also be USB related or if it may also be a hardware connection issue.

On pyboard 1.1 , one of hardware Uart ports, have been getting inconsistent uart.read() at (38400baud) communicating with Win 7 application and printing data through REPL USB connection, that normally works fine with other controller.
At times it receives and prints the uart packets (8-20 characters) OK , at times only receives/prints intermittently and at some other times does not receive/print at all until reset. It appears inconsistent.

Is there any known or similar reported issue?
How does micropython handle uart.read, is it done fully under interrupt and what priority, or is it polled in any way?

[EasyRider]

To add/confirm to previous post.
Serial data from PC is present on pyboard RX input, checked with scope that decodes correctly, and with correct voltage levels.

[dhylands]

By default uart rx is fully interrupt driven and the uart irq is at the highest priority. However this was only changed in late Nov. So if your firmware is earlier than that then the uart irq is at a low priority