2019-07-27 08:55 PM
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:
... 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.
2019-07-29 10:24 AM
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.