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);
}
}
Here's the requested image of the STM32G0B1KBU6N.
I think the issue is not that i didn't know what the IC markings would look like but rather that it never crossed my mind that the fab would place the incorrect processor on such a simple board.
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.
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.
