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, 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
Hi, just some news about our project :
The PCB of the station and remote control are almost ready.
In the same time, Guillaume is working on the bootloader. Brice implements a NMRANet communication thread between can, ethernet and dcc. As for me, i tested if the remote control can be supply by 5V and i’m working on the conversion between Xpressnet (Remote -> Board) and DCC nmranet packet (Board -> Station -> Train).
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,
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 .