0

I've been attempting to set the PLL clock frequency on a STM32H7B3 board, and I was able to do so by setting the DIVN multiplier (RCC_PLL1DIVR_N1) in the code below. The last time I was able to do this successfully was with the multiplier set to 1. When I tried downloading the code with multiplier set to 0x18F (= 399), I got the above error message. I now realize that the max I should have tried was probably DIVN = 280 due to the sys_ck specs, but nonetheless, the error happened upon downloading the code, not running it. I tried using the reset button, but to no avail. I now can't connect to the board and I don't know what else to try.

  RCC -> CFGR &= 0; // Reset register
  int32_t cfgr = RCC -> CFGR;
  int32_t sws_pll1 = RCC_CFGR_SWS_PLL1;
  int32_t status = cfgr & sws_pll1;
  while (!status) {
   cfgr = RCC -> CFGR;
   sws_pll1 = RCC_CFGR_SWS_PLL1;
   status = cfgr & sws_pll1;
  } // System clock switch status: Wait until PLL1 is system clock; TODO: hangs*/
  // RCC source control register
  RCC->CR |= RCC_CR_HSION; // HSI clock enable
  while (!(RCC->CR & RCC_CR_HSIRDY)); // Wait until HSI clock is ready
  /* -------- PLL Config -------- */
  // RCC PLLs clock source selection register
  RCC -> PLLCKSELR |= RCC_PLLCKSELR_PLLSRC_HSI; // Select HSI as PLL clock source (hsi_ck)
  // Note: Must have PLL1ON = 0 for modifying prescaler
  RCC -> PLLCKSELR &= ~RCC_PLLCKSELR_DIVM1; // Reset prescaler for PLL1 to disabled
  RCC -> PLLCKSELR |= RCC_PLLCKSELR_DIVM1_5; // Set prescaler for PLL1 to divsion by 32
  // RCC PLL1 fractional divider register
  RCC -> PLL1FRACR = 0; // Set FRACN to 0
  // RCC PLLs configuration register
  RCC -> PLLCFGR |= RCC_PLLCFGR_PLL1FRACEN; // PLL1 franctional latch enable
  RCC -> PLLCFGR &= ~RCC_PLLCFGR_PLL1VCOSEL; // Select PLL1 output frequency range: wide VCO range from 128 to 560 MHz
  RCC -> PLLCFGR |= RCC_PLLCFGR_PLL1RGE_3; // Select PLL1 input reference frequency range: between 8 and 16 MHz
  // Note: Must have PLL1ON = 0 and PLL1RDY = 0 for enabling divider output
  RCC -> PLLCFGR |= RCC_PLLCFGR_DIVP1EN; // PLL1 DIVP divider output enable
  RCC -> PLLCFGR |= RCC_PLLCFGR_DIVQ1EN; // PLL1 DIVQ divider output enable
  RCC -> PLLCFGR |= RCC_PLLCFGR_DIVR1EN; // PLL1 DIVR divider output enable
  // RCC PLL1 dividers configuration register
  // Note: Must have PLL1ON = 0 and PLL1RDY = 0 for writing bits
  RCC -> PLL1DIVR &= 0; // Reset register
  RCC -> PLL1DIVR |= (0x1 << RCC_PLL1DIVR_N1_Pos) & RCC_PLL1DIVR_N1; // DIVN = 0x18F = 399
  RCC -> PLL1DIVR |= (0x1 << RCC_PLL1DIVR_P1_Pos) & RCC_PLL1DIVR_P1; // DIVP = 1
  RCC -> PLL1DIVR |= (0x1 << RCC_PLL1DIVR_Q1_Pos) & RCC_PLL1DIVR_Q1; // DIVQ = 1
  RCC -> PLL1DIVR |= (0x1 << RCC_PLL1DIVR_R1_Pos) & RCC_PLL1DIVR_R1; // DIVR = 1
  // RCC source control register
  RCC -> CR |= RCC_CR_PLL1ON; // PLL1 enable
  //while((RCC -> CR & RCC_CR_PLL1RDY) == 0); // Wait until PLL1 clock is ready; TODO: hangs

Update: I ran JLinkSTM32, but it printed the following:

Connecting to J-Link via USB...O.K.
Using SWD as target interface.
Target interface speed: 1000 kHz.
VTarget = 3.299V
Reset target...O.K.
Reset option bytes to factory settings...
Option bytes reset to factory settings.
Resetting option bytes failed.
Press any key to exit.
  • Although I generally dislike it, the STM32CubeMX tool has a clock tree tool that will determine the PLL and divider settings for you from constraints such as desired sysclock, I2S, USB, AHB etc. clock rates. If you use it manually, it will highlight conflicts. You don't have to use its generated code, you can just copy the settings into your own code. Given the differences and complexity of clock-trees on various STM32 parts, I'd recommend it. Some older parts have a spreadsheet for this, but you have to wrangle letting Excel run macros to get it to work. – Clifford Jun 11 '21 at 14:51
  • That multiplier value seems insane to me. Last time I did PLL i used something like mul 8 div 2. I agree with @Clifford use the clock tree in my to get the values down. – Sorenp Jun 11 '21 at 17:48
  • @Sorenp I am dividing by 32 using DIVM and by 2 using DIV(P/Q/R), hence the 64 MHz HSI clock becomes 1 MHz, which is then multiplied by the value of DIVN. It's probably higher than it should be but by less than a factor of 2. – Francisco Skrobola Jun 11 '21 at 18:02
  • 1
    @Sorenp I think he is referring to the DIVNx value there rather then the multiplier. STM32 PLLS and clock trees are are very flexible and complex and the H7 is a 280MHz part and can run from a 4MHz external crystal or oscillator and has three separate PLLS. – Clifford Jun 11 '21 at 18:10

1 Answers1

0

Run the command line JLinkSTM32.exe utility (installed with the J-Flash tools), select option 9 (For STM32H7xxxx) and hope (takes a few nervous seconds).

enter image description here

If successful, it may have bulk-erased the flash and will have reset the option bytes for the whole chip. It has got me out of a number of inexplicable lock-out situations not recoverable via the J-Flash GUI tool.

Clifford
  • 88,407
  • 13
  • 85
  • 165
  • I tried running it seems to have a problem with resetting the option bytes. Output is shown above. – Francisco Skrobola Jun 11 '21 at 17:55
  • By the way, these were the two options I was able to select for the H7 series: [9] STM32H743_53_50 [10] STM32H745_47_55_57 I tried both. Are these compatible with the H7B3I? – Francisco Skrobola Jun 11 '21 at 18:09
  • @FranciscoSkrobola Good question, I heart they are newer parts. Do you have the latest J-Flash code? I clearly don't. What device did you select in J-Flash when you programmed it? – Clifford Jun 11 '21 at 19:00
  • I just downloaded it so I should have the latest. – Francisco Skrobola Jun 11 '21 at 19:03
  • @FranciscoSkrobola Weird auto correct! I cannot think what "I heart" was supposed to be! If I had to guess I'd go with H743. – Clifford Jun 11 '21 at 19:13
  • I've tried all at this point and they all fail unfortunately – Francisco Skrobola Jun 11 '21 at 19:31
  • Since the chip at reset runs on an internal oscillator with the PLL off on reset, it is hard to see how you might be locked out. You might try holding it in reset when you start the tool the release it after initiating the unlock or the debugger. It is not really an SO issue now I think. The chip may be irreparably damaged. – Clifford Jun 11 '21 at 19:33
  • One more thing to try - in the J-Flash tool yoy can specify initialisation steps. The step that will be set by default is the reset step, but there you can specify various reset strategies. Try changing it from 0 to 2 (as described here https://wiki.segger.com/UM08001_J-Link_/_J-Trace_User_Guide). It is desperate, but worth a try. – Clifford Jun 11 '21 at 19:43
  • How do I pull the reset pin low? If this is something that needs to be done in JLinkGDBService I can't get that to connect – Francisco Skrobola Jun 11 '21 at 20:13
  • @FranciscoSkrobola Does your board have a reset button? Adding a switch between reset and ground is one way. – Clifford Jun 11 '21 at 20:16
  • It does have a reset button. I've tried various things with it, but what would be the difference between pressing it and pulling it to gnd? – Francisco Skrobola Jun 11 '21 at 20:26
  • @FranciscoSkrobola nothing, you asked me how to hold it in reset, so I assumed there was no reset button or you would not have asked. – Clifford Jun 11 '21 at 20:29
  • Oh, I had assumed reset strategy 2 was something other than pressing the reset button, but yes I have tried that too. – Francisco Skrobola Jun 11 '21 at 20:32
  • @FranciscoSkrobola well it would have better synchronisation and timing with respect to the J-Link than a fat finger perhaps. – Clifford Jun 11 '21 at 20:36
  • So what utility would I use to configure the JLink to pull it low? The Wiki doesn't seem to specify how that should be done. – Francisco Skrobola Jun 11 '21 at 20:37
  • @FranciscoSkrobola J-Flash. Project Options, Init. – Clifford Jun 11 '21 at 20:39
  • Ok, it also fails connecting when I try resetting there. I assume that's about everything that can be tried, but thank you very much for your help though. If you have any more suggestions I can try them as well. – Francisco Skrobola Jun 11 '21 at 20:44