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,
We have found two errors on the PCB Station, the first was just a shutdown sleep on the audio amplifier which wasn’t connected. We sussesfully patched it. The second, was on the ethernet transceiver but the patch was much more complicated and during the operation some pads were deceased. we could have made a new pcb but due to the cost and time we decided to use the old station instead.
The Two stations are linked with a serial cable and it works quite well.
Some other good news, the web server is working (Thanks to lwIP) and it communicates by http. We have begun a simple control interface.
There is some proof:
Some other good news, the buzzer works with the DMA transfer. However, it only works with raw audio files (8bits unsigned @8khz). We also made a map of the railroad. The only things missing for our railroad to work are the sensor cards.
during the previous week I had time to do quite some work for SaMoRa.
I first ported the existing code to our new STMF207VE. In order to do this, I had to create the corresponding linker script and to patch ChibiOS (or more precisely, to hack it) in order to use TIM11 on our board. I also made the CAN implementation of the HAL avalaible for the STM32F2XX family.
I also finished the implementation of most of the OpenLCB standards we will use. This includes most of the Data Link and Network layers, the datagrams and events protocols from the Transport layer and the train control protocol from the Application layer. The CAN specificities are also taken care of. The specific control messages are used and the OpenLCB messages are translated in both ways. The only problem is the translation of messages from nodes not on the CAN. The bridge at the entry of the CAN should automatically create new aliases to send them on the CAN. It was considered unpractical and not useful for our use so they use the alias of the bridge. Furthermore, as some things were not exactly defined, I had to decide on some points. So, even if the code is compliant with the spirit of the standard, it may not work well with another OpenLCB implementations. We finally asked for a range of adresses and received it instantly. We now have the 18.104.22.168.10.(0-255) ID range. It allowed us to determine the exact IDs for all our cards and the exact events we will generate, both for controlling the lights and for receiving information from the sensors.
Next on line is the controller. Based on the file describing the layout of our rails, a python script now generates all the required structures. These structures contain all the necessary information in a usable format, creating an oriented graph with some extra information in independent arrays. The actual implementation of the controller manages all the locomotives, given a complete path for each one (an empty one is valid). It takes care of the reservation of all the segments and switches necessary to a given traject and so prevents crashes. Anyway, that’s the theory, as our railroad is actually unavailable and so the software is untested.
Finally, Guillaume was able to run a program compiled with the -fpic option and launched from his bootloader. Below is an example of blinking LEDs with a program put at address 0×1000.
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
Yesterday we got our PCB soldered, next step is obviously to test it. First happy thing was that the board didn’t get on fire when powering it on.
We created a new ChibiOS project that will be the base for our code. To do things the proper way, we also made a new board folder, which is specific to our PCB. It specifies all the settings of the various GPIOs on the µC, such as the alternate functions.
One minor problem we hit, is that stm32f4 isn’t supported in the openocd build that is running on lab’s desktops, so we had to build master branch of openocd’s git. Thanks to Sam, that was an easy task. After that, the JTAG just worked out of the box.
Once everything was setup, first functions we’ve tested is powering on/off the red led, and the serial port. Testing them made us realize that the serial port has actually been wired the wrong way, TX on the usual RX pin of the micromatch. Hopefully, we aren’t the only group to have failed on that, so we can use SaMoRa’s serial cable .
Another mistake on the schematics we found out, is that one encoder plug isn’t properly usable: one pin is on a timer, while the other one is on another timer. This is no big problem, since it can easily be done in software, and that it seems really unlikely we’ll use encoder.
Yet another mistake on the PCB, is that the plugs aren’t named, so we need a map to know what function is on what plug.
Anyway, despite the various problems, all the features tested are working, so that’s great news !
Yesterday, our PCBs are finished. So, we work about software. Clement worked on remote control and xpressnet protocol, Brice continued to work on NMRA server and compilation chain and I worked on firmware for traffic lights card. Yesterday, we had a problem to flash traffic ligths card and remote control card because they don’t have JTAG. So we should take a python script and we should configure ports to flash card. Yesterday evening we flashed card with success. Now we can test and debug our code on small cards.
see you soon,
With the huge help of Alexis we finished soldering pcbs. Tomorrow we are ready for some real tests and we will give you some news .
3 steps of the PCBs:
First PCB is the Station and the second is an adapter for remotes which use xpressnet protocol like the roco multimaus.
As you may have noticed we don’t have a wifi module. We think that the wifi is very optional and if someone need wifi you can always buy a wifi router and plug him (same price as a wifi module and more configuration).
Erratum : It’s JTAG and not JATG
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).