Upgrade packer and send more FF data

[pkotamnives]

This PR will close #197

The v2 packer has been implemented, and it is compatible with the current set of data steams. This has been checked on Apollo205, and BUTool status looks consistent with what has been shown before.

Next step is to send all FF-ch optical power outputs, ff xmit on output, and more ff register outputs. Some have also been implemented via CLI. The following list is what missing :

• peak temperature? currently we send FF temperature per device
• per rx ch of Received Optical Power(ROP) (currently we send average value of ROP per device)
• LOL has an implementation via CLI ff_cdr_lol
• LOS has an implementation via CLI ff_los_alarm
• missing laser fault (0x9-0x10 for 12-ch or 0x4 for 4-ch)

[pwittich]

@pkotamnives how did you test this? I thought this required a change in the Zynq FW

[pkotamnives]

@pkotamnives how did you test this? I thought this required a change in the Zynq FW

Hi Peter, I first checked the BUTool status from cm_mcu.bin that is up-to-date with the master. Then, I reprogrammed the mcu firmware with the cm_mcu.bin after changing the packer to v2 (no change to data steams) and I see the same status unchanged.

there was a bug that I just fixed though. I can re-check again.

[pwittich]

@pkotamnives how did you test this? I thought this required a change in the Zynq FW

Hi Peter, I first checked the BUTool status from cm_mcu.bin that is up-to-date with the master. Then, I reprogrammed the mcu firmware with the cm_mcu.bin after changing the packer to v2 (no change to data steams) and I see the same status unchanged.

there was a bug that I just fixed though. I can re-check again.

yes please, I think we need a new firmware from @dgastler for this to work. Is it possible you were looking at stale values?

[pkotamnives]

Hi @pwittich and @dgastler, I have reprogrammed mcu with the master cm_mcu.bin. The BUTool status looks good. Then I changed it to the cm_mcu.bin from the latest commit in this branch. I found that the MCU_UPTIME and other fields were frozen after the packer is changed.
This seems to explain why I thought the code works but actually it's not. Could you update the Zynq FW for this purpose?

[pwittich]

Thanks for making the changes! I think there might still be some issues; look at the grafana (I fixed the setup so that it shows up again):
https://www.classe.cornell.edu/cms/grafana/psbATCA/d/YVW4b-n4k/rev2-cm-dashboard?orgId=2&refresh=30s&from=1704213966757&to=1704215766757&var-WhichApollo=AP205
the fact that the values glitch to zero (or non-zero) suggests that we still have some issues with overwriting memory to me....

[pkotamnives]

Update on rollover/overwrite issue: We found that it is a bug in Task.h (i.e. ZM_NUM_ENTRIES = 256 ) that prevents higher address than 0xFF to be written and the program also crashed when more entries than 256 are sent or overwrote to the first table otherwise. We also changed the sensor type from uint8_t to uint16_t just to be consistent with the data type.

Other bugs and corrections as well as the addition of ff_laser_fault to a list of data sent to Zynq will be merged into this branch from https://github.com/apollo-lhc/cm_mcu/tree/test_packer2rollover

[pwittich]

take a look at these changes

[pwittich]

fwiw, this just a dummy value. We don't need to put this in

[pkotamnives]

I'm not sure what your suggestion is

[pkotamnives]

do you mean typing them directly to the code?