First that comes to mind would be Nationals NS16xxx/32xxx series. For data in memory it's little-endian, but displacements and immediate values within instructions are big-endian.
[Official End Of Answer]
[Later AddOn I Couldn't Stop Myself From Doing]
I know, the question does explicit exclude for bi-endian CPUs, but spending some time about the issue, I think there is more to it to be able to simply put it away as a single issue. So please pardon me for going there.
In reality, what often is called bi-endianess isn't a single feature, but a spectrum.
At one end there are CPUs (*1) like MIPS, which offers separate load and store for either endianess. Here byte order is really arbitrary and most definitely nothing to be considered in context of this question.
On the other end we have ARM. The CPU was originally designed as little-endian but a bi-endian mode was added regarding data. Being a RISC CPU it matters only for load and store (*2, *3), but unlike MIPS, it's not done per-instruction but switched via a global flag. Control register 1 holds a bit for endianness. When cleared (like after reset) access is little-endian, otherwise big-endian. Writing that register (
CPRT) is a privileged instruction, making switching anything but casual.
As a result, an ARM CPU with the big-endian bit set fits the question for all operations. Data read from memory are big-endian, while values in instructions (*4) are little-endian. A user-mode programmer has no chance to change this.
So in hindsight, I would place ARM on the list of 'dual endianness ' CPUs. (*5)
To add more confusion, SUN gave us not only SPARC, but increased pressure with UltraSPARC (64 bit), which introduced per (load/store) instruction endianness, much like MIPS. In addition, the MMU got a memory attribute defining endianness for a memory region. Here programs do not have a say about endianness, instead it's done automatically depending on the address which is accessed.
So again, as with ARM, the decision is not in hands of ordinary programmers but defined by the OS. I guess SPARC V9 should also go on the 'dual endianness' list.
P.S.: Interesting question :))
*1 - I use a generic plural here to avoid any discussion how many are there.
*2 - Plus
*3 - Always doing aligned word access; using a non-word address also reorders bytes/words, but that's a different issue.
*4 - Another unusual case for ARM, as by default it knows only an 8-bit immediate value, which can be shifted after loading. In addition there are 12-bit offsets for relative addressing and 24-bit offsets for branching.
*5 - An attempt to use a different word than "bi-endian" to describe a CPU with different code and data endianness.