Fix of reading of IMU magnetometer in boards mtb4, mtb4c, strain2, strain2c

[marcoaccame]

This PR fixes the reading of magnetometer of IMU Bosch BNO055 in some boards: mtb4, mtb4c, strain2, strain2c.

In short: the fix is done by reducing the I2C speed towards the BNO055 and by making sure that the internal CPU and bus speeds are higher.

Description

We noticed that some boards (mtb4, mtb4c, strain2 and strain2c) were reading zero magnetometer values from the IMU Bosch BNO055 which is mounted on their PCB and is accessible via I2C.

On the other hand, the rfe board was behaving correctly.

After careful analysis of the SW and HW differences we found out that if we align the mtb4, mtb4c, strain2 and strain2c to have a higher clock for its internal buses and also if we keep the I2C speed to be standard mode (100 kbit/s) then the magnetometer values are non-zero. Note that the datasheet of the BNO055 allow both standard and fast mode but surely that is not the case w/ our boards.

As a result of that I have aligned the CPU and I2C speeds on the above boards to be as specified in the following table. And that only was enough to fix the reading.

board	I2C speed	CPU speed	Comment
mtb4	100 kbit/s	40 MHz	The I2C speed was already 100 kbit/s. The CPU speed however was 16 MHz.
mtb4c	100 kbit/s	40 MHz	Same as mtb4
strain2	100 kbit/s	80 MHz	The CPU speed was already 80 MHz because they are needed to support FT acquisition at 1 KHz. What is changed is the reduction of I2C speed.
strain2c	100 kbit/s	80 MHz	Same as for strain2
rfe	100 kbit/s	80 Mhz	In here we already had correct speeds for both I2C and CPU. The 80 Mhz are required to manage USB communication for the facial expressions

Table. The CPU and I2C speeds of the boards w/ the BNO055.

Also, I have updated a bit the embot::hw::bno055 driver so that now it is more aligned to the datasheet names and has a more correct boot mechanism performed in runtime during embot::hw::bno055::init(). I have also made sure that the pins used for selecting the communication mode (I2C or USART) are effectively managed by the FW and not only by pull down resistors.

Note that the cleanup of the embot::hw::bno055 driver is a good thing but is not what does the fix on magnetometer.

In order to align the speeds I had to start from the lowest level of of ST Microelectronics's CubeMX sources, the .ioc files, change the HW settings, generate the low level code, use it. However, most of the .ioc file were very old and superseded by a new format and also in the meantime ST Microelectronics has release new HAL libraries. And the boards, being released in different times had all a different version of the STM's HAL.

So, I have aligned all the low level code to the latest .ioc format and to the HAL for L4 MPUs version 1.13.3 (v1D3).

And this alignment and cleanup produced ... thousands of files being changed.

Tests

I have verified that on the mtb4, mtb4c, strain2 and strain2c if we use the configuration of CPU and I2C speeds reported in the above table the values of the magnetometer are non-zero. And they are zero if we use the former configuration.

Tests by @Nicogene also confirmed that: see robotology/icub-tech-support#1485 (comment)

Important

In icub-firmware-build new binaries will be published for the application, the bootloader and the updater of the bootloader, BUT ... to fix the behavior it is enough to update the application only and not also the bootloader.

[marcoaccame]

Following tests by @Nicogene in here, I am going to merge this PR. A PR w/ the relevant binaries will soon come thanks to @Nicogene.