Upgrade packer and send more FF data

apollo-lhc / cm_mcu

Microcontroller source code for the APOLLO blade for the CMS tracker HL-LHC upgrade.

MIT License

2 stars 2 forks source link

Upgrade packer and send more FF data #201

Closed pkotamnives closed 5 months ago

pkotamnives commented 7 months ago

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 commented 7 months ago

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

pkotamnives commented 7 months ago

@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 commented 7 months ago

@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 commented 7 months ago

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 commented 6 months ago

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 commented 5 months ago

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