2024-01-30 06:25 AM - edited 2024-01-30 06:50 AM
Hello,
we have an electronic with two possible µC as footprint on the PCB.
STM32L071CZ
STM32L071KZ
Inside the layout it was necessary to route two signals to different GPIOs, therefore
we have a difference in the configuration.
We want to avoid a #define to distinguish between both firmware with different GPIO settings
for these two signals.
Is there any chance to distinguish between these both µC by any register that we can read?
Greetings
Stefan
PS1:
CPUID -> does not work, it doesn't contain information about the package
PS2:
We tried to use
#define IOUTENA_PIN_49Pin GPIO_PIN_2 // BGA
#define IOUTENA_GPIO_PORT_49Pin GPIOC
#define IOUTENA_PIN_32Pin GPIO_PIN_1 // QFP
#define IOUTENA_GPIO_PORT_32Pin GPIOA
if (IS_GPIO_PIN_AVAILABLE(IOUTENA_GPIO_PORT_49Pin,IOUTENA_PIN_49Pin))
But this doesn't work also. We guess that both packages contain the same Die, therefore
the GPIO is available on both µC, but NOT connected to a package pin for both packages.
Solved! Go to Solution.
2024-01-30 06:53 AM
Utilize differences in the schematic to determine which is which. For example, if PA0 is tied to GND on one of the boards, initialize it as input with pullup and read its value. If it's low, you know that's the board where it's tied to ground.
This is not written anywhere but it has worked for me: For pins that exist on one chip but not the other, and that can be driven, you can initialize them as output high and read their value. If it's low, that's the chip where the pin doesn't exist. Not guaranteed, but may work for you.
2024-01-30 06:53 AM
Utilize differences in the schematic to determine which is which. For example, if PA0 is tied to GND on one of the boards, initialize it as input with pullup and read its value. If it's low, you know that's the board where it's tied to ground.
This is not written anywhere but it has worked for me: For pins that exist on one chip but not the other, and that can be driven, you can initialize them as output high and read their value. If it's low, that's the chip where the pin doesn't exist. Not guaranteed, but may work for you.
2024-01-30 07:10 AM
@SJung.1 wrote:Inside the layout it was necessary to route two signals to different GPIOs, therefore
we have a difference in the configuration..
As @TDK said, make use of that difference in routing.
If you have a spare pin available, use that to identify the system.
STM32L071CZ = 48/49 pins
STM32L071KZ = 32 pins
So the CZ has 16/17 pins that aren't available on the KZ; they appear to include PC13, PB2, PB10-15 - so you could use any of them as (an) "identity" pin(s) ....
2024-01-30 07:20 AM
@Andrew Neil wrote:So the CZ has 16/17 pins that aren't available on the KZ; they appear to include PC13, PB2, PB10-15 - so you could use any of them as (an) "identity" pin(s) ....
Yes, that will work, but not on already existing PCBs. We need a firmware solution for existing PCBs,
therefore i wrote "Inside the layout it was necessary to route". Maybe it was not clear enough what i mean.
2024-01-30 07:22 AM
@TDK wrote:This is not written anywhere but it has worked for me: For pins that exist on one chip but not the other, and that can be driven, you can initialize them as output high and read their value. If it's low, that's the chip where the pin doesn't exist. Not guaranteed, but may work for you.
I just checked the schematics and in our case the GPIO is on a pullup resistor to 3.3V.
Therefore your solution seems to be the best solution. We will check this and I will report back here.