Extended information about UCB blocks

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
µCGuru334
Level 2
Level 2
5 questions asked First like given 10 replies posted

Hello everyone.

Is there any further information (application notes, sample code) on the subject of the Aurix UCB block's?

The specific meaning, practical use, erase and program cycles of the 47 different UCB blocks would be very interesting.

I can't find any further information on this topic at  https://myicp.infineon.com/sites/microcontrollers-aurix_customer_doc ->   00 AURIX TC3xx General   ->  00 to 05

Thank you

0 Likes
1 Solution
cwunder
Employee
Employee
5 likes given 50 likes received 50 solutions authored

When dealing with with the UCB's the main caution is do not update them unless you know what you are doing.

If you incorrectly program a UCB you can permanently lock yourself out of the device and then it can only be used as a paperweight.

The User Configuration Block (UCB) provides non-volatile settings to the Startup Software (SSW) that runs after every reset to configure the device.

The UCB's are part of the Data Flash and represent individual 512 byte sectors and have a limited number of programming cycles (see the datasheet). Do not constantly be erasing/programming them. This can cause the device to become unusable. Make sure to check what you are doing with a debugger that they are not updated every time you update your code.

The UCBs that the user can configure come from the factory in an erased state (except the for the Confirmation code).  Never erase a UCB and perform a reset before writing the confirmation code to that UCB.

The User's Manual part 1 (chapter 6.8.2.1) is the place to start. Some of them will have redundancy (such as the orig or copy) others have specific rules on how they would be read by the SSW. Some have 256-bit passwords. So that you can place protections for debug access, OTP/WOP sectors, read/write program protections and so on. You also need to know the section "6.5.4.3 Configuring Protection in the UCB". This tells you what the UCB state is (in practice the UCB should either be UNLOCKED or CONFIRMED). There are usually associated registers that the SSW will populate from the value of the UCB that you can read. For example take the UCB_DBG_ORIG/COPY

cwunder_0-1693327532795.png

The PROCONDBG value programmed in the UCB can be read in the register DMU_HF_PROCONDBG

cwunder_1-1693327672006.png

Note the registers indicate they are "rh" which means the SSW will write this from the UCB values.

You can also see for some UCB's which ones were used by the SSW by viewing the SCU_STMEMx registers (see section 3.2.1.1 Registers providing information on the boot selections).

The UCB's come in a state so you only need to program them (no need to erase before writing the first time).
Generally, for development the only UCBs you need to configure are the UCB_BMHDx_ORIG/COPY.

When you are really for series production then you would lock down the device with all the protections and change the UCBs to the confirmed state.

If you have questions I would advise you to ask before programming. You can post specific questions to this forum or contact your local Infineon FAE for help.

View solution in original post

1 Reply
cwunder
Employee
Employee
5 likes given 50 likes received 50 solutions authored

When dealing with with the UCB's the main caution is do not update them unless you know what you are doing.

If you incorrectly program a UCB you can permanently lock yourself out of the device and then it can only be used as a paperweight.

The User Configuration Block (UCB) provides non-volatile settings to the Startup Software (SSW) that runs after every reset to configure the device.

The UCB's are part of the Data Flash and represent individual 512 byte sectors and have a limited number of programming cycles (see the datasheet). Do not constantly be erasing/programming them. This can cause the device to become unusable. Make sure to check what you are doing with a debugger that they are not updated every time you update your code.

The UCBs that the user can configure come from the factory in an erased state (except the for the Confirmation code).  Never erase a UCB and perform a reset before writing the confirmation code to that UCB.

The User's Manual part 1 (chapter 6.8.2.1) is the place to start. Some of them will have redundancy (such as the orig or copy) others have specific rules on how they would be read by the SSW. Some have 256-bit passwords. So that you can place protections for debug access, OTP/WOP sectors, read/write program protections and so on. You also need to know the section "6.5.4.3 Configuring Protection in the UCB". This tells you what the UCB state is (in practice the UCB should either be UNLOCKED or CONFIRMED). There are usually associated registers that the SSW will populate from the value of the UCB that you can read. For example take the UCB_DBG_ORIG/COPY

cwunder_0-1693327532795.png

The PROCONDBG value programmed in the UCB can be read in the register DMU_HF_PROCONDBG

cwunder_1-1693327672006.png

Note the registers indicate they are "rh" which means the SSW will write this from the UCB values.

You can also see for some UCB's which ones were used by the SSW by viewing the SCU_STMEMx registers (see section 3.2.1.1 Registers providing information on the boot selections).

The UCB's come in a state so you only need to program them (no need to erase before writing the first time).
Generally, for development the only UCBs you need to configure are the UCB_BMHDx_ORIG/COPY.

When you are really for series production then you would lock down the device with all the protections and change the UCBs to the confirmed state.

If you have questions I would advise you to ask before programming. You can post specific questions to this forum or contact your local Infineon FAE for help.