[StabiloRose] VBUS

Today, we started to code for our board. The switching power supplies are working well and controlled by the STM32. Interrupts are generated if they are not stable. Everything went fine… Until we tried to implement the serial over USB module, and the shell. We were stuck for a loooooong moment. Impossible to obtain anything. It was like the STM32 was not connected to the laptop. We confirmed that it was not an hardware issue by communicating with the preinstalled USB bootloader of the STM32.

After checking the schematic, we (Thanks for all Dryvenn) pointed out the problem. The PA9 is the default pin for VBUS. Ours is connected to the buzzer, with a pull-down resistor. As the STM32 couldn’t detect if any cable was plug-in, it have never engaged the communication.

The problem is solved by defining the symbol BOARD_OTG_NOVBUSSENS in board.h. Now we have to manage the cable detection “manually” with interrupts.


[STM32F4] End of the labwork and the challenge


This week, we have to finish the stm32 labwork and what a mess! I was not early. However, I got a really good experience. I’m now able to drive leds with pwm, handle buttons and trim, and even create a tcp client.
The most difficult part was the tcp client, we had to modify the lwipthread.c file and a lot of functions came from “nowhere”. When I have understood how it works, I see how it is powerful. Now, I still have some troubles : the connection is not very fast and many connections in a loop don’t work perfectly.

For the challenge, I have succeed two steps and have reached the third too late. It was around 18h45 and it stopped earlier this year : 19h30. Maybe, it was possible but I feel tired… During the morning, something strange is appeared. I have implemented a function which was called in my tcp client. But in fact, it was never called and even in gdb. In gdb, it was missing! I will find the commit and try again at home. If the problem is still present, I really want help from the teachers in order to discover the mistake. In the afternoon, I have changed and have implemented an other technique. I have learned how to use MailBox in chibios aka queue.

Today, I solve a strange behavior from my board at home. I have implemented a thread which toggles a led every time something on the serial is received. At the beginning of each program, the led was toggling ten times and I got back this : “AT?PORT”. Other students have had problem today with the serial and it was owing to the modem manager. Thus, when I came back home I discovered that modem manager was in my fedora too. Like I expected, after removing it, it worked so well!

Until now, let’s go back to the project!


[challenge] What a day !

I had imagined many scenarios for this day, but certainly not this one. To answer your question Drix, yes the progress animation was there. It was funny, but also very destabilizing. Could you imagine that in the preparatory exams for the Grandes Ecoles ? Every one becomes crazy ! On the one hand it is very stimulating and emulates the competition. On the other hand, it reassures you. I was not the only one to be stuck at step one in the afternoon.

In fact, my code was not robust enough and I spent many hours on debugging it. Then, I had a revelation around 5pm, which gave me only a few hours to progress on the challenge. I can still remember Sam’s eyes saying “Another one who haven’t listen…”, when he was checking my work… And he was right. After cleaning all this, the coding was more fluid. It brings me out of my grumpy mood and my bad faith.

Above all, the challenge really was a good experience. I understood a lot about debugging, and errors management in particular. I must correct the code of the practical work and make it clearer now. The more I use ChibiOS, the more I enjoy it. There is a big step to understand it in the beginning. But it turns out to be very powerful and easy to use.

At present, we have to focus on the code of our project… but not tonight.


The Lab is over


I just have finished the STM32 lab. Now, I can use some basic features as the LWIP, the serial over USB, the buzzer and much more.

These elements will be very useful for the communication challenge of tomorrow but also for our project.

See you soon, bye !

[ChibiOS] What a day !

Today was a big day. I had to finish the implementation of a simple http client before the challenge of tomorrow, to get familiar with the LwIP stack and the netconn API. It’s almost done. I haven’t tested it with telecom-paristech.fr because the site was down for a few hours this afternoon. I tested with my laptop as a web server, only with netcat. I received the http get and the response was correctly redirected on the serial over USB channel. By the way, the port 80 seems to be blocked on the computers of the a406 room. I mean, with netcat listening to the port 80 on my laptop, I couldn’t established any connection from another computer in the room, even if both were connected with Ethernet.

I’m not inspired tonight, so I am going to continue with these little mistakes or, let’s say carelessness, I made today. The first of all dealt with endianness. I only used static IPs, so I hardcoded them. This was a really bad idea. With a little-endian processor and a big-endian network, you could imagine the disaster. Then I worked with the echo server set up by Alexis. After a few tries (at least one hour), the communication was impossible. The server was down. About this point, I plead guilty.

But this is nothing compared to the netconn API documentation. Between the ambiguity of the explanations, the broken links, and the “@todo explain netbuf”, I was completely lost. I allocated memory for the buffers where I should not, I used functions reserved to UDP…

Anyway, this is over. I give you another funny picture, from Geek & Poke this time.

Endianness (from http://geek-and-poke.com/)

[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: Expectations vs Reality


TP and tp again

Since last week end, I’m working on the STM23F4 tp. I have discovered the callback method by implementing a pwm. However, I have got a surprise too. I firstly believed that the JTAG was working but in fact it didn’t. I have had to modify board.h again and after it worked.

Yesterday was a full day, from morning until night but very instructive. I have implemented the buttons, the potentiometer, the buzzer and finally the serial over usb.

Today, I have seen that I have got a problem with my serial. The datareceiver callback was called but after the mcu panicked. I solved this problem after hours of debugging. I have taken so much time because, the “same” code worked with Dimitri. The fact was the problem was not in main.c but in chconf.h. I have set to TRUE a debug option which was not necessary (CH_DBG_SYSTEM_STATE_CHECK). This option forbids the use of functions during interruption like sdWrite. Thus, I have used an another thread which are handle by Event (Broadcast and EventSource).

Next, I will stop using serial functions but serial over usb functions, work on the tcp/ip.



Getting Sidetracked by Interesting Protocols

Today, I lost a lot of time.

Actually, I didn’t lose any time, I just didn’t use it for what I had intended in the first place. I hoped to finish the assignment within the deadline, that is today; instead I learned a little about USB and standard libs.

I started by trying to use the serial-over-usb module of ChibiOS, but faced with the complexity of the USB protocol, I ended up adapting the demo code rather than reconstructing it. To my surprise, it didn’t work ! That is, even when only compiling the demo code, it would compile fine, but never actually expose a recognizable device to my computer . Instead, I would be getting confusing “device descriptor read error” messages in my dmesg, and packet inspection via wireshark/usbmon indicated that the packets were malformed. After some fiddling about and dirty “switch the usb off and on again until it works” hacks, I could see the device descriptor, but not its configuration, so still far from a serial-over-usb communication.

After a few hours of hair pulling, I switched workstations, and it worked on the first try, with the exact same code, only a different compiler ! I guess I’ll be sticking with the official ARM toolchain from now on, to avoid any unpleasant surprises like this.

In the end I still learned some basics about the USB protocol, and I also tried to make ChibiOS compile with clang. I have no more compilation errors, but it’s still not linking unfortunately. I guess this little side-project will have to wait, though, because I still didn’t finish the assignment in the end…

Some games with STM32

Hi everyone,

as Julien said, the robotics course was very far from what we expected.
Anyway it was difficult to help my team and I think I missed a lot of things about PCB, that’s too bad. SO I worked the TP on the STM32.

Chibios do not assume PWM on each GPIO of our board, so I though I have just to look at PWM function on other pins, and copy them with just putting the good register. However it seemed much more complicated than just “changing two or three register” so I decided to use some callback from a PWM on another GPIO. This method is easier but the results are less accurate. It seems to work very well with our baby program, but I think we should implement the real PWM and not use callbaclk if we have to sell our program.

Then I implemented interrupts on push buttons and  an ADC on the potentiometer of the board.
Finally I tried to use USB port as a seriel communication port and first try seems work.

Next step is to use buzzer, which would be PWM (and assumed by ChibiOS this time), and the network configuration to use TCP/IP protocol.

PCB achieved

This week-end, we have made the routage on PCB Expedition. A lot of mistakes, but now that’s alright!

I have used the STM32CubeMX software in order to create a graphical STM32 pins view. The result is easier to read than in an excel file and you can verify your configuration.
I was in charge of the Power Supply specification and to put it in our wikipage on GitHub. Firstly, I didn’t understand the goal and I put the highest current supported by each component. Alexis has corrected me, he has created only one bulleted list for each voltage (one 3.3V in HeRos) and add the peak current for our need . The current was less intensive !