Difference between revisions of "Burning new firmware in v1495"
From PolWiki
Jump to navigationJump to search| (6 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| + | Following is an example of burning a firmware in the v1495 which is slave-2 of the v1495's in ccomptvme2. | ||
| + | |||
* You need to login into the CPU of the crate which has this v1495 using telnet or minicom. | * You need to login into the CPU of the crate which has this v1495 using telnet or minicom. | ||
| − | telnet | + | telnet ccomptvme2 |
* change your directory to the place where you have the firmware saved | * change your directory to the place where you have the firmware saved | ||
| − | cd "/home/cdaq/ | + | cd "/home/cdaq/compton/firmware/" |
* check if the list of files to confirm the new firmware in this location | * check if the list of files to confirm the new firmware in this location | ||
ls | ls | ||
| Line 8: | Line 10: | ||
ld < v1495.o | ld < v1495.o | ||
* check the VME bus address to which this v1495 is mapped. by running the sysBusToLocalAdrs command followed by printing the value. | * check the VME bus address to which this v1495 is mapped. by running the sysBusToLocalAdrs command followed by printing the value. | ||
| − | sysBusToLocalAdrs(0x39, | + | sysBusToLocalAdrs(0x39, 0x220000 , &laddr); |
printf("0x%x\n",laddr); | printf("0x%x\n",laddr); | ||
: '''1st parameter''': 0x39 stands for 24 bit addressing on my v1495 board, which could have been 0x09 in 32 bit addressing mode. | : '''1st parameter''': 0x39 stands for 24 bit addressing on my v1495 board, which could have been 0x09 in 32 bit addressing mode. | ||
| − | :'''2nd parameter''': | + | :'''2nd parameter''': 0x220000 is the hardware address set by me on the v1495-slave-2, by setting the Hexa decimal dip switches on the top of the board to '0','0','2','2'. the last 4 bytes are automatically '0' |
| + | :'''slave-0''' has a hardware address of 0x200000 | ||
| + | :'''slave-1''' has a hardware address of 0x210000 | ||
| + | :'''slave-2''' has a hardware address of 0x220000 | ||
| + | :'''slave-3''' has a hardware address of 0x230000 | ||
| + | |||
:'''3rd parameter''': laddr is a local variable (stands for local address), (if it is not already defined, then enter "laddr =0" in the CPU terminal to create a variable with that name) | :'''3rd parameter''': laddr is a local variable (stands for local address), (if it is not already defined, then enter "laddr =0" in the CPU terminal to create a variable with that name) | ||
| − | * finally run the function v1495firmware to burn in the binary file into the EEPROM of the v1495. | + | * finally run the function v1495firmware to burn in the binary file into the EEPROM of the v1495. For example if you want to burn the fimware named ''v1495cp_master_rAA0A.rbf'' on the (master) v1495 board, which has a hardware address of 0x200000 then you enter |
| − | v1495firmware( | + | |
| − | : '''1st parameter''': | + | v1495firmware(0x90200000,"v1495cp_master_rAA0A.rbf",0,0) |
| − | : '''2nd parameter''': | + | |
| + | Similarly you want to burn the firmware ''v1495cp_4stripTrigCluster_r3217.rbf'' in all the slave v1495's you can execute the following command, while logged into the CPU of the crate which has the these v1495 boards. | ||
| + | v1495firmware(0x90210000,"v1495cp_4stripTrigCluster_r3217.rbf",0,0) | ||
| + | v1495firmware(0x90220000,"v1495cp_4stripTrigCluster_r3217.rbf",0,0) | ||
| + | v1495firmware(0x90230000,"v1495cp_4stripTrigCluster_r3217.rbf",0,0) | ||
| + | |||
| + | : '''1st parameter''': 0x90220000 is the local VME bus addr of the v1495, corresponding to my hardware addr of 0x220000, found in step 5 | ||
| + | : '''2nd parameter''': v1495cp_4stripTrigCluster_r3217.rbf is the name of the (raw binary format) file that you want to burn into the User FPGA memory of the v1495.(in the local directory/folder where you call this function) | ||
: '''3rd parameter''': 0 stands for writing in ['1' for reading out] | : '''3rd parameter''': 0 stands for writing in ['1' for reading out] | ||
: '''4th parameter''': 0 stands for User FPGA ['1' for Bridge FPGA] | : '''4th parameter''': 0 stands for User FPGA ['1' for Bridge FPGA] | ||
| − | This will take around | + | This will take around 2 minutes. wait until that time, after which I see a message: |
| − | Updating firmware of the FPGA USER with the file | + | Updating firmware of the FPGA USER with the file V1495CP_32bit_r320E.rbf |
End of file: bp=112 bcnt=444952 | End of file: bp=112 bcnt=444952 | ||
Firmware loaded successfully. Written 444952 bytes | Firmware loaded successfully. Written 444952 bytes | ||
Reloading user FPGA firmware...done! | Reloading user FPGA firmware...done! | ||
| − | + | Make sure that you see the message about successful reloading. The function is now configured such that we do not need to reboot the crate for the new firmware to be loaded, but it is a good pratice to do so before going in for production run. | |
Latest revision as of 11:30, 27 April 2011
Following is an example of burning a firmware in the v1495 which is slave-2 of the v1495's in ccomptvme2.
- You need to login into the CPU of the crate which has this v1495 using telnet or minicom.
telnet ccomptvme2
- change your directory to the place where you have the firmware saved
cd "/home/cdaq/compton/firmware/"
- check if the list of files to confirm the new firmware in this location
ls
- load the object file corresponding to the CAEN provided lib. [This library has the function 'v1495firmware' defined]
ld < v1495.o
- check the VME bus address to which this v1495 is mapped. by running the sysBusToLocalAdrs command followed by printing the value.
sysBusToLocalAdrs(0x39, 0x220000 , &laddr);
printf("0x%x\n",laddr);
- 1st parameter: 0x39 stands for 24 bit addressing on my v1495 board, which could have been 0x09 in 32 bit addressing mode.
- 2nd parameter: 0x220000 is the hardware address set by me on the v1495-slave-2, by setting the Hexa decimal dip switches on the top of the board to '0','0','2','2'. the last 4 bytes are automatically '0'
- slave-0 has a hardware address of 0x200000
- slave-1 has a hardware address of 0x210000
- slave-2 has a hardware address of 0x220000
- slave-3 has a hardware address of 0x230000
- 3rd parameter: laddr is a local variable (stands for local address), (if it is not already defined, then enter "laddr =0" in the CPU terminal to create a variable with that name)
- finally run the function v1495firmware to burn in the binary file into the EEPROM of the v1495. For example if you want to burn the fimware named v1495cp_master_rAA0A.rbf on the (master) v1495 board, which has a hardware address of 0x200000 then you enter
v1495firmware(0x90200000,"v1495cp_master_rAA0A.rbf",0,0)
Similarly you want to burn the firmware v1495cp_4stripTrigCluster_r3217.rbf in all the slave v1495's you can execute the following command, while logged into the CPU of the crate which has the these v1495 boards.
v1495firmware(0x90210000,"v1495cp_4stripTrigCluster_r3217.rbf",0,0) v1495firmware(0x90220000,"v1495cp_4stripTrigCluster_r3217.rbf",0,0) v1495firmware(0x90230000,"v1495cp_4stripTrigCluster_r3217.rbf",0,0)
- 1st parameter: 0x90220000 is the local VME bus addr of the v1495, corresponding to my hardware addr of 0x220000, found in step 5
- 2nd parameter: v1495cp_4stripTrigCluster_r3217.rbf is the name of the (raw binary format) file that you want to burn into the User FPGA memory of the v1495.(in the local directory/folder where you call this function)
- 3rd parameter: 0 stands for writing in ['1' for reading out]
- 4th parameter: 0 stands for User FPGA ['1' for Bridge FPGA]
This will take around 2 minutes. wait until that time, after which I see a message:
Updating firmware of the FPGA USER with the file V1495CP_32bit_r320E.rbf End of file: bp=112 bcnt=444952 Firmware loaded successfully. Written 444952 bytes Reloading user FPGA firmware...done!
Make sure that you see the message about successful reloading. The function is now configured such that we do not need to reboot the crate for the new firmware to be loaded, but it is a good pratice to do so before going in for production run.
