Unfortunately there will be no R-Box BMW in the second half of the 2016 rally season.
Despite everything was looking very good until last week, we are forced to take a very painful decision.
It’s pretty easy to capture that we were looking forward to our first event with the M3 after almost 6 years of hard work.
Despite the enormous disappointment, we have to move on and as a famous soccer player quoted a long time ago “every drawback will have his advantage”.
In the mean time we are back in full force solving the issue and we banned those dark clouds forever to a desert island far from here.
For sure it will take a few months, but of course we have learned a lot so we will improve several things so that our car will become even more unique!
What went wrong …
When we started the development for the TFT screens we were convinced that it was a smart choice to make our own interface board with all connectivity to our car, and plug on a standard processor module as a buy part to cut cost and developing time.
There are plenty of SOM (System on Module) makers available on the market today.
And even Emcraft was designing one with a Microsemi Smartfusion2 SoC, which was exactly the part that we would like to use as processing unit
Although it was very early stage, we knew before that it can be very challenging to be an early adapter, we were quite confident with the expertise and connections we have with Microsemi that we could bring it to the end.
The first Emcraft module had a M2S050ES on board which is engineering silicon in a FG896 package. The integration went quite well, we had very good support from the local Microsemi team and from Emcraft as well.
Despite bugs were discovered on a regular base we never had a real show stopper.
And of course we were aware that a production version from the SOM was coming in the near future.
By the time the new SOM arrived we were already quite far in the developing phase. Same for the interface board, we had our 8 prototypes available already for a while.
When we saw the preliminary datasheet of the new SOM we noticed that the package of the FPGA was changed from FG896 to FG484. For the less technical people from a bigger package to a smaller package with fewer balls (the old one is the middle one on the picture while the right SOM is the new one)
Since there are only part of the IO’s (approx 160) routed to the high density connectors this was not necessarily a problem. So the supplier guaranteed 100% compatibility. So all good.
Of course this package change had also some consequences for our design. We had to change all previous pinning in the software. Because we were not feeling very excited to re-connect everything manually in the design environment, I spent some time making an excel conversion sheet to find and replace all IO pin numbers in our previous physical constraints file.
And even Emcraft was designing one with a Microsemi Smartfusion2 SoC, which was exactly the part that we would like to use as processing unit
Although it was very early stage, we knew before that it can be very challenging to be an early adapter, we were quite confident with the expertise and connections we have with Microsemi that we could bring it to the end.
The first Emcraft module had a M2S050ES on board which is engineering silicon in a FG896 package. The integration went quite well, we had very good support from the local Microsemi team and from Emcraft as well.
Despite bugs were discovered on a regular base we never had a real show stopper.
And of course we were aware that a production version from the SOM was coming in the near future.
By the time the new SOM arrived we were already quite far in the developing phase. Same for the interface board, we had our 8 prototypes available already for a while.
When we saw the preliminary datasheet of the new SOM we noticed that the package of the FPGA was changed from FG896 to FG484. For the less technical people from a bigger package to a smaller package with fewer balls (the old one is the middle one on the picture while the right SOM is the new one)
Since there are only part of the IO’s (approx 160) routed to the high density connectors this was not necessarily a problem. So the supplier guaranteed 100% compatibility. So all good.
Of course this package change had also some consequences for our design. We had to change all previous pinning in the software. Because we were not feeling very excited to re-connect everything manually in the design environment, I spent some time making an excel conversion sheet to find and replace all IO pin numbers in our previous physical constraints file.
Taking this route was by far the easiest and we only had to re-run the complete flow with the new pdc file.
It went pretty well, as wel synthesis, compile and P&R passed without issues.
From that moment we replaced all old SOM’s and continued with the development based on the new final production versions. So far so good.
Actually we were almost finished since a while, except we still had a few minor issues that we had to clean up some time. This software clean up happened last week. Because this minor SPI issue tended to become a naughty one, I decided to add some debug signals to connect a protocol analyzer.
It went pretty well, as wel synthesis, compile and P&R passed without issues.
From that moment we replaced all old SOM’s and continued with the development based on the new final production versions. So far so good.
Actually we were almost finished since a while, except we still had a few minor issues that we had to clean up some time. This software clean up happened last week. Because this minor SPI issue tended to become a naughty one, I decided to add some debug signals to connect a protocol analyzer.
I was astonished when I realized that the debug signals could not be connected to the free pins that were routed to the debug connector. Libero, the design tool has a kind of automatic design rule check when a user tries to for example to hook up signals that do not match the voltage levels, it prohibits the connection.
That’s how I realized that both SOM’s are not fully compatible. They didn’t took care about the IO bank division and mixed up the 3V3 and 2V5 IO’s.
In other words a complete disaster for us !!
Initially I tough only a few IO’s were affected but when I started checking them one by one, I quickly found out it were dozens.
For those who are less technical, if a certain peripheral (which is on out interface card) wants to talk to a 3V3 IO from the processor, it puts a high (1) or low (0) on that line. A high means almost 3V3. If now by means of the new SOM this processor IO is only 2V5 instead of previous 3V3 you will over stress that IO all the time. This will still work but you can imagine it’s bad for the lifetime of the processor.
And does anyone remember which was are top most important spec? Exactly, reliability !!
The really bad news is that these old SOM’s are not on the market anymore, only the new with the for us mixed up IO banks (since we based our design on the old SOM spec) are available.
Conclusion :
- We can trough all are 8 boards in the bin what results in +10K euro loss without taking in account the endless hours of work we put in.
- We are obliged to do a re-design meaning, schematic capture, layout, PCB manufacturing, re-buy all devices, have the boards produced, testing,… so again the same range of cost.
- And another 4-6 moths delay.
You will not find any SOM in our new board, we don’t want to become again dependent on a SOM supplier. As common in electronics technology changes very rapidly so we will use for sure some new stuff on the design, especially the communication part will be significantly updated.
It was a extremely painful and very expensive lesson, but we are even more motivated now.
Being in a situation where we can implement new features heals a bit the pain.
It will become even more spectacular and with a bit of luck, maybe this will be implemented not only in the R-Box BMW.
To be continued …