Check behavior of silicon version check in 2FOC test procedure

[MSECode]

We need to double check how the check for the silicon version in the phase1 of the test procedure is made on the fw side, so that we can let the test pass when a board has a newer silicon version that the minimum required one. Basically we are not 100% sure if the test step passes for older or newer version. Need to check and eventually update.

cc: @valegagge @fgarini

[MSECode]

It seems that the silicon version is just match with a specific value:

but I need to double check this since it is hard to understand which is the source code the test is using. I saw that on another section where we actually have all the test code the silicon version is checked as here:

thus I'm not sure in which case the test can fail

[fgarini]

Ciao @MSECode I investigated on this topic
The microcontroller is DSPIC33FJ128MC802
the information about the existing revisions is available in the silicon errata sheet:

As you can see the latest revision is the 0x3004. We can think to include in the good version list 0x3005 eventually, even if I'm not expecting new silicon revisions on a quite old uC.

The test could fail for example if an old batch of microcontroller reaches the market (like it happened during global shortage) and we can have problem with our firmware if the missing/broken functionality is not correctly handled.
representative about this fact is that the information is reported also in wingst:
so it must be a critical issue.

[MSECode]

Thanks @fgarini, good to know.
So, looking at the version I suppose that we actually do this check:

which matches the version defined in wingst too. I think now to modify the test so that we can accept version not only equal to 0x3003 but also higher. Moreover, we can say that we won't to let boards with a silicon version lower than 0x3003 pass the test if I understood correctly from your notes since having a revision higher than that is critical.

[fgarini]

Yes I think at the time when the code was written the version 0x3004 wasn't already issued and the reading triggers the error as in the latest snippet you posted.

[valegagge]

Ok, so we can proceed to add version A5 (0x3004), but I think it is better to avoid adding 0x3005 which currently doesn't exist.

What do you think @MSECode and @fgarini ?

[MSECode]

That makes sense, I'm not sure if set a check that matches the exact versions, but I would prefer to just see if the silicon version is grater or equal to a specific one, in our case 0x3003, so that if other version will come out we do not need to modify the code.

[MSECode]

I've started to add the updates here: https://github.com/MSECode/electronics-legacy/tree/feature/update2FOCtest
adding the programming of the 2 cores of the 2foc with bootloader and firmware at the beginning of fase2.xml and updating unclear instructions in default.xml

[MSECode]

I've studied how to manage this test. Two solutions were possible, one that uses the operation type recvrange and one that uses the operation type recvpassfail and adds a method one the fw.
I've decided to use this latter option, which in my opinion is easier to manage and to understand.
Anyway, at this commit https://github.com/MSECode/electronics-legacy/commit/42493588c4c12b7d1b0b204fa32ef4db417ee526 you can find the details about the changes done.
What comes now is to test that using the test equipment.

[MSECode]

As discussed w/ @valegagge we still have some problems regarding the fw for the test on the 2FOC, which I'm gonna explain here.
First thing first. We need to modify the code for fixing/updating the silicon version check. NOTE: currently we are quite sure, by checking both fw and xml files, that the test fw is just checking the version retrieved from the board EEPROM with the values 0x3004, which is the latest one as mentioned here. However, as per info reported on wingst we would like to let also version A4 pass, i.e. 0x3003. Thus, this is the reason why we are doing this update.
As introduced here there are 2 possible solutions I was thinking about:

1. First option. I have some doubt about it feasibility since I'm not sure how the values passed by the CAN message in the xml file are received in the fw. So, looking at the documentation of the xml files here: https://github.com/icub-tech-iit/electronics-legacy/blob/master/projects/proposal/P2011_14_ETS/docs/TechnicalSpecification/SC2011_EDL_ETS_0000.docx, I found that there is a type of operation called recvrange. Therefore, I thought that we can substitute the current operation message with this one:
   <operation type="recvrange" hex="1" max="0x3004" min="0x3003">0xfe 0xff 0xff 0x8c</operation> , but I'm not sure about 2 points:
   1.1. How min and max values taken by the current fw since I cannot see in the parser how those values are read: https://github.com/icub-tech-iit/electronics-legacy/blob/master/projects/boards/P2009_05_2FOC/test/SW/Src/can_proto_parser.c#L338-L357
   1.2. Is the current fw send as output a transmission payload (which is the version to be checked). Is that type of operation already made to read it and perform the check or this is not possible. Since the documentation does not have examples and this type of operation is never used in our xml files we need to test how it works to be sure.

2. Second option. I would modify the test operation in the xml in this way:
   <operation type="recvpassfail" hex="1" reportpass="1" reportfail="1">0xfe 0xff 0xff 0x8c 0x00 </operation>, so that we are using the same type and we can keep the output of the test cleaner. However, for this solution I thought to modify the fw as shown in this commit: https://github.com/MSECode/electronics-legacy/commit/42493588c4c12b7d1b0b204fa32ef4db417ee526. In this way, I think that:
   2.1. the solution is cleaner
   2.2. we can have different errors and eventually the value of the retrieved silicon version to help the tester in understanding eventual errors
   However, this solution opens to one problem: I'm not sure how to re-compile the code for generating the executable to include in the final executable for the 2FOC tests. I'm saying this because:
   2.3. First point, looking at this link mentioned in the wiki of ETS: https://github.com/icub-tech-iit/electronics-legacy/tree/master/projects/boards/P2009_05_2FOC/test/InstallPackage/src that point to the final install package I supposed that the source code used for generating the 2FOC test fw is stored at the folder: https://github.com/icub-tech-iit/electronics-legacy/tree/master/projects/boards/P2009_05_2FOC/test/SW but there I cannot find any project file to open it on MPLAB IDE. On the contrary the only MPLAB IDE project file is stored at: https://github.com/icub-tech-iit/electronics-legacy/tree/master/projects/boards/P2009_05_2FOC/sw/2FOC/2FOC_EDL.X. However, this leads to another question: how can be this be the correct source code if in the file can_proto_parser.h some of the tests are missing, such as the 0x40, use for checking the overcurrent, while that is present under the .../P2009_05_2FOC/test/SW folder?

Thus, the point to be discussed are:

1. How we wanna update the test
2. In general, which is the correct source code to generate the final executable (This I think is important also for future improvements)

cc: @valegagge

[MSECode]

After discussion w/ @valegagge, and considering that the 2FOC boards are soon to be deprecated, we have decided to apply a small workaround to solve the problem of the checking of the silicon version that just need the user to modify the xml file. Therefore, there's no issue with the source code.
As per the other issues related the PR that solves the problem is this one: https://github.com/icub-tech-iit/electronics-legacy/pull/80