cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F103 "Device electronic signature" unreadable after USB init

I can usually read my STM32F103XB's "Device electronic signature" ("Flash size register" and "Unique device ID") both by "using the JTAG/SWD or the CPU", as per that quote from the RM0008 documentation. The correct addresses hold values of 0x0080 (indicating 128 Kbytes of flash memory) and 96 seemingly random bits for the device ID.

But somewhere after initializing the chip to do USB device communications, including:

  1. Setting the main clock to 72 MHz
  2. Initializing the USB peripheral, including its 48 MHz derived clock, and
  3. Going through the complex sequence of interrupts and register writes necessary to "enumerate" (USB protocol) the MCU to the USB host ...

... the 5 32-bit words starting at 0x1ffff7e0 all read 0xffffffff, both from code running on the CPU, and via SWD. This persists until the MCU is reset.

Any insights? Is there some undocumented limitation on reading these addresses, like wait states being required if the core clock is set at too high a frequency? As a workaround I read the device ID first thing in main() with everything at post-reset defaults, but this really belongs later in the code path and I'd like to understand what's going wrong.

1 REPLY 1

Update: Happens as soon as main clock set to 72 MHz (has nothing to do with USB enabling, etc).

(gdb) x/5xw 0x1FFFF7E0
0x1ffff7e0:	0xffff0080	0x051406b5	0x066cff48	0x53497550
0x1ffff7f0:	0x87114331
(gdb) n
96	    while((RCC->CR & RCC_CR_HSERDY) == 0); /* Waiting to switch to PLL HSE */
(gdb) 
99	    RCC->CFGR |= RCC_CFGR_HPRE_DIV1 | RCC_CFGR_PPRE2_DIV1 | RCC_CFGR_PPRE1_DIV1;
(gdb) 
102	    RCC->CFGR &= ~((RCC_CFGR_PLLSRC | RCC_CFGR_PLLXTPRE | RCC_CFGR_PLLMULL));
(gdb) 
104	    RCC->CFGR |= RCC_CFGR_PLLSRC;      /* Clock PLL to HSE (8 MHz) */
(gdb) 
105	    RCC->CFGR |= RCC_CFGR_PLLMULL9;    /* Multiply frequency on 9 (8*9=72 MHz) */
(gdb) 
107	    RCC->CR |= RCC_CR_PLLON;               /* Run PLL */
(gdb) 
108	    while((RCC->CR & RCC_CR_PLLRDY) == 0); /* Waiting to switch to PLL */
(gdb) 
110	    RCC->CFGR &= ~RCC_CFGR_SW;      /* Clear bits SW0, SW1 */
(gdb) 
111	    RCC->CFGR |= RCC_CFGR_SW_PLL;   /* PLL selected as system clock */
(gdb) x/5xw 0x1FFFF7E0
0x1ffff7e0:	0xffff0080	0x051406b5	0x066cff48	0x53497550
0x1ffff7f0:	0x87114331
(gdb) n
113	    while((RCC->CFGR & RCC_CFGR_SWS) != RCC_CFGR_SWS_1);
(gdb) x/5xw 0x1FFFF7E0
0x1ffff7e0:	0xffffffff	0xffffffff	0xffffffff	0xffffffff
0x1ffff7f0:	0xffffffff

Don't know if it happens with other main clock or PLL sources, or other PLL clock frequencies. Still curious if anyone else has seen this or has an explanation.