How to split uint32 into four uint8 in efr32
Your example as shown won't work, because you're using pointer arithmetic wrong, and are missing a key referencing (&amp;) step. You're also trying to initialise a value of type uint32_t as it it was an array (uint32_t*), which it isn't.
The code *(Tx_PP+8) in C will take the uint32_t value (not pointer), add on to it 8, then read the value at that address. This will give you a memory address of 0x02F003E7 + 8, which is not in any way a byte within Tx_PP (well, it could be by sheer luck but it most likely wont be).
I think what you intended to write was *(&amp;Tx_PP + 8) which would take the address in memory where the value of Tx_PP is stored (a pointer to it), offset the pointer by 8 * sizeof(uint32_t), and then dereference it to get the value. However this would again be incorrect as it would point to a memory address 32 bytes further into the memory, not one.
Instead you would need to cast the referenced pointer to a uint8_t* and then add 1 to move to the next byte.
arr[1]=*(((uint8_t*)&amp;Tx_PP)+1);

Of course that's kind of ugly. There are cleaner alternatives.
One option is to use memcpy or similar:
memcpy(arr, &amp;Tx_PP, sizeof(uint32_t)); //Copy bytes from Tx_PP into array

You could also use an intermediate pointer:
uint32_t Tx_PP = ...
uint8_t Tx_PP_int = (uint8_t)&amp;Tx_PP; // Note: It is ok to cast down to byte, not to cast up to larger values due to potential address alignment issues.
arr[0] = Tx_PP_int[0];
arr[1] = Tx_PP_int[1]; // or *(Tx_PP_int+1)
arr[2] = Tx_PP_int[2];
arr[3] = Tx_PP_int[3];

In that second example, a for loop could be used rather than writing it out four times - which is essentially what memcpy does.

A StackOverflow duplicate was linked in the comments which upon reading the answers their raises a third example:
*(uint32_t*)arr = Tx_PP;

This basically treats arr as if its a single 32-bit number rather than four 8-bit numbers. I would strongly advise against using this. Unless arr happens to start in memory on a 32-bit boundary, this kind of cast can easily result in unaligned access errors.