[STM32G0B1KBU7N] GPIO not working

[XD_it]

Not sure what is going on, im unable to toggle an IO and im not sure why...

This is a very simply custom board, it uses I2C, CAN and USB. I've configured everything in CubeMX and double checked the pinout and gerber files several times but i can't find anything wrong. I've double checked the voltages on VDD and VDDIO2, both are 3.3V. 

I've tried configuring PD2 as Push-Pull and Open drain with and without pull-up but i get no change on the pin when measuring with my scope.

PD2 is connected to the CAN STBY pin that has an internal pull-up, the pin remains high when the PHY is connected and low when the PHY is disconnected. This would indicate that there is no short on the board and that the electrical part is fine. 

I have physically probed the connections on the board and they are correct.

What am i missing, do i need to configure something else?

 

Below is the minimum CubeMX project. I2C and the EXTI work fine but PD2 does not. 

 

int main(void)
{

 /* USER CODE BEGIN 1 */

 /* USER CODE END 1 */

 /* MCU Configuration--------------------------------------------------------*/

 /* Reset of all peripherals, Initializes the Flash interface and the Systick. */
 HAL_Init();

 /* USER CODE BEGIN Init */

 /* USER CODE END Init */

 /* Configure the system clock */
 SystemClock_Config();

 /* USER CODE BEGIN SysInit */

 /* USER CODE END SysInit */

 /* Initialize all configured peripherals */
 MX_GPIO_Init();
 MX_I2C1_Init();
 MX_FDCAN1_Init();
 /* USER CODE BEGIN 2 */

 while(1){

	 HAL_GPIO_TogglePin(GPIOD, GPIO_PIN_2);
	 HAL_Delay(500);

 }
}

 

[Ghofrane GSOURI]

Hello @XD_it 

I'm currently investigating this behavior.I will get back to you ASAP.

It would be useful if you could provide your IOC.

THX

Ghofrane

[XD_it]

Hi @Ghofrane GSOURI , 

 

I have attached the CubeMX file, i can provide the entire CubeIDE project if needed. But It's simply the HAL toggle code in the main loop. 

 

 

 

[TDK]

Are you sure the part number is correct? Try toggling PB4, which is in the same pin position on similar chips.

Step through the code and look at bit 2 in the GPIOD->ODR register and see if it lines up with bit 2 in the GPIO->IDR register. If it does, the pin is behaving correctly.

 

PD2 is related to the UCPD2_CC2. You may need to disable that.

Solved: STM32H573V UCPD CC2 and PC9 interference - STMicroelectronics Community

[waclawek.jan]

Either this:

> Are you sure the part number is correct?

i.e. you in fact have the non-N-suffixed part, 

or you don't have properly connected VDDIO2 pin.

or something else, in which case read out and check/post content of GPIOD registers.

JW

[XD_it]

Hi @TDK  & @waclawek.jan, 

I made sure to triple check the BOM and the other manufacturer files i sent to the fab. I had specified the N-variant, se below. 

 

Checking the IC marking shows that it is in fact not the N variant. Could anybody confirm this before I involve the fab?

First time i've got a similar processor but not the one i specified in the BOM, got to be the first for everything....

 

[Lina_DABASINSKAITE]

Hello @XD_it, 

Thank you for being a valued member of our community. Your post has been escalated to the ST Online Support Team for further assistance. Our team will contact you directly to provide the necessary support. We appreciate your patience and understanding as we work to address your concerns.

Please note, that all product marking related questions should go through our Online support team: https://ols.st.com/s/  

Best regards,
Lina

[AScha.3]

So just try: set the pin D2 to -> B4 , GPIOB , pin 4 . Check...toggle.

[XD_it]

PB4 toggles the PD2 pin.

It seems that the fab placed the non N-variant...

[novaksta]

Hello,

I confirm according to provided information, it seems is fitted GP version instead of N (as @TDK/@waclawek.jan assumed, thank you).

With regards,

novaksta

[waclawek.jan]

Hi @XD_it ,

I have a request: as you probably are going to get the proper N-suffixed parts, once you get them, could you please post photo of them here, for others to have a reference?

Thanks,

JW

[XD_it]

@waclawek.jan, I've ordered a few of DigiKey to attempt swap the wrong one out. I should get some next week, and ill order a new set of boards but they'll arrive at least 6 weeks from now. 

May I ask why you need photos of the IC markings?
To detect counterfeits?

 

Long story short:
I contacted the fab and they apologized and claimed that the N-variant was simply for the extended temperature range. A bit of back and forth with pictures and links to the datasheet pointing out that they were wrong. They did eventually offer to refund the order since it was a handful of simple prototype boards. 

[waclawek.jan]

> May I ask why you need photos of the IC markings?

Not me personally.

It would benefit anybody who comes across the same problem as you in the future.

The point is to highlight the differences in the marking. I know, the marking changes, but generally, the differences should hopefully stay roughly the same.

JW

[waclawek.jan]

Thanks.

OK so they omitted the "package type" letter (U) to fit in the "extra" "N". 

That's not exactly expected and IMO this ought to be documented in the DS and/or TN1433, preferrably both.

> it never crossed my mind that the fab would place the incorrect processor

While the fab is guilty too, placing a vital part of the marking beyond the "lesser" (memory size, package type and temperature range) is IMO a major mistake on ST's part. Would I be responsible for such decision, I would make the disctinction directly in the package digits/letters (i.e. here "KxU" may be well changed for e.g. "KxV" or something along those lines) but maybe I would even go as far as highlighting the disctinction by changing the last digit/letter in the "principial" part of the marking (i.e. here I'd use STM32G0B2 or STM32G0BA or similar). I would avoid *adding* suffixes to *functionally different* parts at all costs.

The same goes for the "SMPS" variants (suffixes P, Q).

JW

PS. Once one knows what to look for, the distinction between non-suffixed and N-suffixed part can be found out also by reading the device's signature, maybe even CubeProgrammer supports this? 

The mess this issue is can be seen also in how the suffixed/non-suffixed disctinction is marked as "Power Delivery" and "N-version" in various models, within the same page. ST, it's you who invent the nomenclature, please strive for consistency.

 

[XD_it]

I've also experienced lackluster documentation, especially from the HAL or other tools.

I quickly tried to read the Package data register from CubeProgrammer but I can't seem to read any register below 0xE000ED04.

It would be a nice feature to add to CubeProgrammer since one of the first things I looked for was the device ID and type. I don't think that there is a way to know exactly what variant is used (other than looking at the UUID and referencing a database). At least they could add the Device electronic signature register to the register menu.