Today, we had a hard day.and many problems to communicate on the CAN bus.
- First problem, the configuration of CAN bus. There are many timing configurations. Particularly for the synchronisation of each node on a frame. So we decided to use the nmra standard at 125 Kbits/s. It’s relatively slow but we had many difficulties to go faster.
- Then, we tested the bootloader to send many frames and we were able to flash the first boards but the others were too far on the bus and they didn’t receive any frame. During the afternoon, we realized that last boards were not enough electrically supplied. Indeed, at the end of the bus we had only 2.4V. Therefore, we increased the voltage supply and we were able to flash all the boards with the bootloader.
- After that, we fixed some bugs in the lights, sensors and bootloader’s firmware. Now, we can flash the firmware of each board with the bootloader by the CAN bus and we can control the lights and listen to sensors through the bus.
- To finish, we rewired the CAN bus and we put the railroad on the table.
just some pictures of ligths for fun
Tomorrow, we will work on the station and we will probably test the controller.
Today, Brice worked about Server. He is able to send commands to train and base station translate this in DCC to lead trains and switches.
Bootloader runs. we put it on all cards and we will not need to flash all cards individualy. So we are able to flash all cards of a specified type in one time.
This bootloader has two parts:
- One part is on the station and another part is on all daugther boards. This part receives the new firmware (compiled in 0×08004000) by serial port and it sends this firmware on CAN bus. The first frame is a BEGIN_UPDATE frame. Since the boards have the correct ID receive this frame and they switch in update mode and they erase their old firmware. After base station sends frame with data (new firmware) and all cards in update mode write this new firmware in flash. Finally, base station send reset frame and all cards reset on the new firmware.
Tomorrow, we will try to merge all modules like traffic ligth board and sensors.
See you soon,
Today, we worked respectively on bootloader, traffic sensors and CAN HAL.
- Bootloader is very difficult to implement. We have to complete crt0.c of ChibiOs. We have to copy vector table and got section in RAM to add offset of these relatives address. Now, we are able to branch the main but after there are a bug.
- CAN HAL is in progress. We will test it soon.
- Traffic sensors work but code will be improved tomorow. And we need to inface this node with the base station. Moreover we dumped packets between booster and remote, to analyze the protocol.
Pictures of our experiments
We are trying to generate a position independent executable with a relative vector table adress in order to be able to flash the firmware at any adress. At this time, we have still lots of bugs and errors. But we can read/write/erase the flash. Seeing that the update over can is soon ready we have rewired all the table.
Here is a table of what we have to do (sort by priority)
|Port Station on STM32F207
|Bootloader / Recovery Firmware
|Redesign virtual nodes
|Traffic Lights and Sensors
Today, we worked on the bootloader 0. We updated him in order to be able to switch in recovery mode after a cold boot.
Just to remind this bootloader is for cards of trafic light, switch and remote control. The last version switch in recovery mode only if firmware 1 and 2 crash. So if the update function have a bug, it’s impossible to update the card.
Moreover, the recovery mode is a very simple firmware which is able to listen CAN Bus and update or remove firmware and reset the card.
EDIT : A light optimization we reset after cold boot and without recovery instruction.
See you soon,
First of all, I would like to apologize for not having given you news about Ball-E for such a long time.
Let me make a short summary of where we are now.
Before the Athens week, we decided several components of our robot and we received most of them. Actually, we have our 3 stepping motors (Trinamics QSH5718), our two-rows 4″ omniwheels (Kornylak). With Pierre-Hugues, we made the pin assignment of our STM32405RG-based card and finished the schematic of our PCB. Routing will be done as soon as Alexis will have corrected our schematic. Scott and Otilia are working hard in order to implement a Kalman filter and to understand a huge part of the mechanics.
Alexis lent us a card with an accelerometer, a gyroscope and a magnetometer so that Otilia and Scott can test their Kalman filter. Pierre-Hugues is going to code tomorrow a bootloader which will make the card dump the values of the sensors through the usb port.
My objective of tomorrow is to build the whole robot so that it will be ready for real tests when we will receive the PCB.
Since Monday, Brice work on the protocol CAN to be fully compatible with the NMRANet standard while Guillaume and me work on the can bootloader and how to update firmware of the boards over the CAN.
Two schemes about our work :
On this first, you can see that we have make a static repartition of the 128kB ROM. At the begin we have the Bootloader with a recovery firmware, then some flags and at the end we keep 2 firmwares and 2 configs.
With this procedure we are able to check after n steps if the last firmware fail, and then back on the previous. And if the previous fail after n steps we jump to the recovery firmware and are able to flash over the can.
In conclusion, we think that we have to be very bad programmers if we want to brick our cards.
Reply in next weeks .