[ChibiOS] Multithreading

After the anger comes the frustration. After being stuck a few days on the serial over USB implementation on ChibiOS, I finally did it ! It was yesterday evening. I was in a good mood this morning. Actually, making a success of compiling and flashing a demo code is not very glorious. The rules are clear : no black magic ! However, after many comparisons with my original code, I could not figure out where were my mistakes.

The general survey and advice of today have been helpful. My problems came from the multithreading. Firstly, I thought that when main returns, it would be sleeping forever. In fact, it seems to be stuck in an infinite active loop. Because of this active wait, the serial over UBS, which had the same priority, could not be executed properly. (The management of SDU was made in a thread, not in the main function) Instead I saw a lot of 110 errors in dmesg. 110 means “not enough power supply to provide to the device”. It logical from the point of view of the host. The STM32 acted like it was establishing a connection, and stopping. And started a new one and so on, like a device which is constantly rebooting because it not powered enough.

A few patches later, it is now working properly. I am pretty impressed by the shell. It is very easy to enable and customize. You can add you own commands, see the number of threads, the state of the memory. Very useful.

Well, I hope I will remember this episode during my future debugs. I leave you with this picture you might have already seen.

Multithreading

Multithreading: Expectations vs Reality

 

3 comments to [ChibiOS] Multithreading

  • Phh

    Nice image 🙂

    A minor note:
    The 110 error is not “not enough power supply to provide to the device”, it is exactly what you just said before.
    It actually means timeout: the Linux kernel detects a new device, it is asking the device to give its descriptors, but the device doesn’t give them (because the USB thread isn’t available to send descriptors)
    So the kernel give up waiting for the descriptors, and says there has been a timeout.

    Those error codes are standard across the whole kernel, and even to userland, they are matching “errno” values.
    You can search one error code with goold old friend grep:
    > grep 110 /usr/include/*/*errno*
    Which gives:
    /usr/include/asm-generic/errno.h:#define ETIMEDOUT 110 /* Connection timed out */

    To extend further than microcontrollers, you can see that all syscalls (calls from userland to kernel) on Unices are using those error codes:
    > man 2 connect
    There is a section called “ERRORS” with a list of possible errors on open. Here we can see again ETIMEDOUT being reused for a totally different use case, but still the same meaning “Connection timed out”

    And good luck fighting your next multi-threading problem 🙂

  • Which tool did you use to get the error number (110)?

  • clestrelin

    @Phh, Thak you. I didn’t know that.

    @Drix, I simply used dmesg, which reads messages from the kernel.