New release for IPTS, to test boards MTB4 (12008.C) and STRAIN2(11996.C)

[icub-tech-iit]

New release for IPTS, to test boards MTB4 (12008.C) and STRAIN2(11996.C)

[davidetome]

I confirm that also on the strain2.C boards, the led DL1 is reversed.
Thanks to @MrAndrea for fixing it on 2 of 4 boards provided by the supplier 👍🏻

So, as for now, the blinky led app runs on both boards.

cc @maggia80 @Fabrizio69 @pattacini

[davidetome]

I created the CubeMX prj also for strain2; I'm able to flash the board but, unfortunately, the LED doesn't blink.
Tomorrow morning I'll check if the LED is correctly soldered.

cc @maggia80 @pattacini @MrAndrea

[davidetome]

Thanks to the training I had w/ @marcoaccame , Today I managed to test the CAN communication for the mtb4.B test application.
I then inserted the first basic 3 tests (here the project) :

• Chech test Firmware version
• Test LEDs OFF
• Test LEDs ON

As we can see, sending the corresponding command the mtb4 reacts accordingly :

VID_20220527_135407.mp4

Next sprint I will go on adding the other tests and better formatting the code.

[davidetome]

This morning I had a T2T w/ @marcoaccame and we solved the GPIO config problem.
So the mtb4.B test FW w/ the embot framework is fully working.

This afternoon we had another meeting where @marcoaccame showed me how to produce the new stm32hal lib for the new micro.
We also produced a basic demo project (blinking led) and I tested it successfully.

Next steps are :

• verify some params in the CubeMx project
• modify the mtb4.B test project w/ the new lib for themtb4.C.
• verify everything works

cc @pattacini @maggia80

[davidetome]

The mtb4.C test FW is ready.

Today I tested the new firmware w/ the IPTS suite.
Since I review also the FW for the mtb4.B using the embot framework I tested it too.
Everythink works:

0000_12008.B.txt
0000_12008.C.txt

⚠️ For the C revision the final programming of bootloader and application is not possible since I have to modify them w/ the new library for the new uP; finally we need also to make some changes to the high-level code in order to make themtb4C board usable

cc @pattacini @marcoaccame @maggia80 @Fabrizio69 @emilianob80

[davidetome]

ciao @Fabrizio69,

yesterday I managed to produce the new bootloader and I'm going to do the same for the application; anyway, we need to modify some pieces of software too (icub-firmware-shared, icub -main..) and test them accurately before merging.
So what I propose to do is to make the first release of IPTS containing local binaries (at least bootloader), in this way the boards will be discoverable and updatable.

Once the binaries are merged, we can make a new release letting IPTS pull the binaries from the repo as usual.

Sounds good to you?

cc @pattacini @marcoaccame @maggia80 @MrAndrea

[davidetome]

Started w/ MTB4 CubeMx prj, unfortunately is not possible to retarget the existing prj to the new uP even if it is fully compatible.

I picked up from @icub-tech-iit/proto :

• MTB4 test equipment SN002
• ST-LINK debugger SN B201833
• DB9/molex CAN cable w/ USB PS (@gsisinna )

I'll bring all back once finished 👍🏻

cc @pattacini @maggia80

[davidetome]

I tested a blinky led app for the mtb4 and I noticed that all the boards have the blue led reversed (@MrAndrea fixed it on 2 boards 🎖️ ), I'll add the tests then.

Now I'm going to test a blinky led app also on strain2 in order to see if also these boards at least are alive and programmable as requested by @maggia80.

cc @pattacini

[davidetome]

@MrAndrea I would wait also to check strain2 and adapt test firmware to the new stm32l452 uP since we may notice other issues
We already agree w/ them to come at CRIS once test firmware are ready to pick up the boards and test equipments

cc @pattacini @maggia80 @Fabrizio69

[davidetome]

I had a T2T w/ @marcoaccame and, as anticipated, the problem belongs to the old library used for the test FW and it is also not compatible w/ the new uP.

Apparently, it boils all down to the CAN driver change.

We tried to fix porting the library used to the one used by the official application but it seems to require a certain effort.

Seen that we thought it might be worth to port the test FW using the same library of the application and using the framework we use for our boards (not low-level HAL); this surely requires an effort but it could be a good exercise for me to better understand the FW environment, also for future needs..

Otherwise, we have to adapt the test FW using a newer library.

cc @pattacini @maggia80

[marcoaccame]

We'll do this first on the mtb4.B as we know everything works; then we'll port the project w/ the new uP

So, the plan is this one.

• Create in icub-firmware a new test application for the mtb4 (version B) which is a simplification of bootloader. The test application will just manage basic CAN communication using the embot::hw::can driver which we use in all our recent boards. The parsing of the CAN frame will be left out at first.
• Add the specific parsing of CAN frames used for testing plus the associated actions. This is what is already available in here and used to perform the test.
• Make sure that the test application works fine w/ the current setup on the mtb4 version B.
• Build the stm32hal library for the new mtb4c board (version C) using cubemx as described in here (with any version of HAL driver we want) and use it with the test application as described in following point.
• Copy and adapt the test application developed and tested for the mtb4 board so that it can work with the stm32hal library for the new mtb4c board.
• Use the new test application to validate the mtb version C boards

At this point we can surely test the new boards but we can also produce very quickly the bootloader and application and updaterofbootloader for the new mtb4c board.

And for the new strain2c we shall only need to build the stm32hal library for the new micro.

[davidetome]

Today I managed to add the remaining tests for the mtb4.B w/ the embot framework.
Everything works but a GPIO that I need to make as output; on Monday I'll ask @marcoaccame..

0002_12008.B.txt

Then we can move to the new lib for the new uP.

cc @pattacini @maggia80

[davidetome]

New release of IPTS w/ mtb4c test support is available.
The link has to be provided to the supplier.

cc @pattacini @Fabrizio69 @Andreamenini68

[davidetome]

Regarding the bootloader and application adaption, in particular about :

• Compile the mods and check that FirmwareUpdater correctly recognizes the mtb4c

I managed to compile my forked icub-firmware-shared and FirmwareUpdater correctly recognizes the new board mtb4c

Now I've to check the functionality (i.e. upload app via FirmwareUpdater, skin, IMU, temperature)

cc @pattacini @marcoaccame @maggia80 @MrAndrea

[davidetome]

@Fabrizio69 , I'm going to give @Miche19 the 10 mtb4c boards provided.
The two ones marked with a white dot are tested and working.

cc @maggia80 @MrAndrea @Andreamenini68

[davidetome]

Just added the CubeMx prj for mtb4.C in my fork w/ this commit

[pattacini]

Nice!

[davidetome]

Added mtb4c bootloader and application in my icub-firmware fork.
The board is correctly discoverable :

The board is still unknown due to the fact I have to compile icub-main w/ the mods pushed in my icub-firmware-shared fork.

The next steps are :

• Compile the mods and check that FirmwareUpdater correctly recognizes the mtb4c
• Do some tests w/ the new applications (skin service, IMU service, temperature service)

cc @marcoaccame @pattacini @maggia80 @MrAndrea @Fabrizio69

[Fabrizio69]

Hi @davidetome tell us when a new release for the IPTS is ready for the supplier.

[Fabrizio69]

Hi @davidetome it's OK for me, thanks

[Miche19]

@Fabrizio69 , I'm going to give @Miche19 the 10 mtb4c boards provided. The two ones marked with a white dot are tested and working.

cc @maggia80 @MrAndrea @Andreamenini68

ricevute da @davidetome

[davidetome]

@Fabrizio69 I think it would be worth keeping one mtb4c in order to test the new bootloader and application.
It's ok with you?

cc @pattacini @marcoaccame @maggia80 @Andreamenini68

[davidetome]

Closing this in favour of #9

[MrAndrea]

We have to contact the supplier to ask for the replacement of the blue led DL1 with the right mounting.
Which is the order corresponding to this batch production? this one?

[davidetome]

Hi @marcoaccame , as anticipated I'm facing some problems w/ the mtb4 test FW.
I tried to compile the old prj w/ the same ST library used in icub-firmware but the CAN driver seems to be changed from the oldest library I used.
So I tried to compile the new prj w/ the same library I used but I got errors on CAN driver as well.

As agree, please let me know a time slot convenient for you on Monday so I can show you in particular

[pattacini]

this surely requires an effort but it could be a good exercise for me to better understand the FW environment, also for future needs..

👍🏻

[davidetome]

This morning I had another T2T w/ @marcoaccame ; as anticipated we started having an overview of the basic apps for pmc (as an example) and mtb4.

We decided to start from the bootloader project of the mtb4 that contains the basic functionality we need (a thread that waits and responds to the CAN bus) and add the functions that perform the tests from the old test firmware.

We'll do this first on the mtb4.B as we know everything works; then we'll port the project w/ the new uP

cc @pattacini @maggia80

[Fabrizio69]

Hi @davidetome , from the previous comment I understand that we can't send to the provider, the boards tor the test (see purcase issue. Is it correct?

[davidetome]

@Fabrizio69, I can make the release by today, and give you back the 10 mtb4c boards on Wednesday morning.
Let me know if it is ok for you!