Auto reflow QC tests on STM32F215

[neoirto]

Posted on March 28, 2016 at 18:59

Hi,

I would like to share an idea here about a way to auto-test our boards (based on STM32F215 LQFP64) to prevents shorts in both contexts:1. after reflow process as partial QC,2. during the product life: after each startup to eventualy detect transitory shorts in relation with water on the board, bad usage etc...The idea would be, using the internal clock, to test the initial state of each pin of the MCU, regarding its surrounding neighbours, to detect reflow bridges, shorts...Our initial idea is to use this kind of schem for 3 surrounding pins:- pinA: INPUT -> NO_PULL : GPIO_Read()- pinB: INPUT -> PULLUP during few ms, then PULLDOWN for another few ms- pinC: INPUT -> NO_PULL : GPIO_Read()By reading state of pinA and pinC during pinB level changes, we probably can detect a lot of potential shorts, what do you think?Exluding NRST and BOOT0 and BOOT1 to prevent bad behavior?Just after the reflow and before (1.) a takaya process will first test for main shorts:- on alimentation VDD, perhaps VBAT, NRST too?- is it necessary to test VCAP1 and VCAP2 regarding surrounding pins (VDD and PB11 and PA13) with the takaya, or is it safe to activate a pullup or pulldown on the closest pin if a reflow bridge is formed?Same question about PH0 and PH1 (OSC_IN and OSC_OUT), running on internal clock is it pertinent to activate pullup and down the time of this test?Thanks in advance for your feedback on it!

[neoirto]

Posted on April 03, 2016 at 18:20

Hi all,

Anyone to help on that subject please?Could you please help us to identify what pins we need to check with the flying probe to detect minimal configuration to power the STM32F2 without damaging antything?PowerNRSTPA0BOOT0 / BOOT1Is it correct?After this first pass, we can power the board with the TAKAYA and check 1.2V on VCAP1 and VCAP2?Then our firmware can detect eventual shorts on the board with internal pullup we can use on each pin of the MCU? Perhaps except pulldown PA0 to avoid RESET?Another question about JTAG pins: which of these pins can we use has digital I/O: all except JRST?Thanks for helping please!!

[Danish1]

Posted on April 04, 2016 at 12:43

How about external current-limiting to how you apply power during first production test to avoid damage due to components? You have to be sure not to exceed the absolute-maximum ratings, but worst-case operational current drain should be well under this.

As regards testing ''in the field'' during the lifetime of the device, it is extremely difficult to cater for the effects of water because that is likely to give rise to leakage (high resistance) paths rather than ''obvious'' short-circuits.Hope this helps,Danish

[neoirto]

Posted on April 04, 2016 at 23:51

Thank you for your answer,

When you say:

How about external current-limiting to how you apply power during first production test to avoid damage due to components? You have to be sure not to exceed the absolute-maximum ratings, but worst-case operational current drain should be well under this.

You mean I have to care about peripherals reaction when line is under pullup or pulldown isn't it? Internal resistor are given for R>30K, is that true?So yes, on many lines, it will be ok...The flying probe can help us on sensitive peripheral lines to avoid this problem what do you think?About minimal configuration to test before powering STM32, what are the minimal pins to test please?Tx again 🙂

[Danish1]

Posted on April 15, 2016 at 16:00

(I am disappointed that no-one else has added their thoughts).

My view is that you don't _need_ to probe NRST / PA0 / Boot0 / Boot1. Although it is true that the cpu will never start up properly with those stuck, before the cpu comes out of reset it is not running so all pins are in an indeterminate state anyway. Your external hardware must survive the situation before the cpu comes out of reset, so I don't see the specific need to probe lines to confirm that it will come out of reset.If you program the stm32 before putting it onto the pcb (I don't know if you're allowed to do this - I've never checked for that in the data sheet) then if the cpu does not start properly you will never get the ''signature'' of a passed self-test - whatever your code does to test the board's functionality.If you don't program the stm32 before mounting it then having the vital lines tied will mean that you're unable to download your code. You should also be able to spot this.So my approach is not to bother looking for problems but simply to attempt to program the stm32 once my board is fully populated. I am careful about how I apply power at this stage such that if my main voltage-regulator is short-circuit then I do not exceed the absolute-maximum ratings of the processor (or anything else on board). If the programming succeeds then the stm32 can my self-test and e.g. look for shorted traces or problems with external circuits. If the programming fails then I know one of the critical nets e.g. Boot, Reset, JTAG is stuck or open.It's probably worth pointing out that my manufacturer, as a matter of course, runs an optical inspection of the board looking for bad solder joints and/or misplaced / ''tombstoned'' components.Hope this helps,Danish

[neoirto]

Posted on April 23, 2016 at 11:26

Tx a lot Danish for your answers!

My last question is about external crystal (8 MHz).Saying startup is done on HSI at first:- is it safe to run this kind of pullup and pulldown tests on the Xtal pins OSC_IN and OSC_OUT to detect shorts?- what is the OSC_IN/OSC_OUT pullup/down configuration that will induce a XTal oscillation?-if an oscillation is induced by this first test using HSI, how can we we stop it? Both OSC_IN and OSC_OUT in pulldown?- after these tests, we just have to run HSE external Xtal??Thanks again, hope this post will help other STM32 users running internal QC 😉

[Danish1]

Posted on April 23, 2016 at 17:24

I think a much better test for the crystal would be to turn on the oscillator (HSE_ON?) and see if it becomes ready (HSE_RDY?) within a reasonable time-period. This checks for opens and components as well as shorts.

You might have to go low-level and access the appropriate registers directly rather than use ST's library to do this. (I look at ST's libraries to help me understand how to do things, but I do not feel obliged to _only_ use their code unmodified).Hope this helps,Danish

[neoirto]

Posted on April 24, 2016 at 20:46

Hmmm, interesting... Of course it helps, thank you Danish!

I am not experienced in starting HSE inside main() after HSI configuration in startup. Can you eventually point me to a code example please?Tx anyway!

[Danish1]

Posted on April 26, 2016 at 14:29

Looking in STM32F4xx_DSP_StdPeriph_Lib_V1.3.0/Libraries/STM32F4xx_StdPeriph_Driver/src/stm32f4xx_rcc.c (nb: there might be a later version) I see:

/**

  * @brief  Configures the External High Speed oscillator (HSE).  * @note   After enabling the HSE (RCC_HSE_ON or RCC_HSE_Bypass), the application  *         software should wait on HSERDY flag to be set indicating that HSE clock  *         is stable and can be used to clock the PLL and/or system clock.  * @note   HSE state can not be changed if it is used directly or through the  *         PLL as system clock. In this case, you have to select another source  *         of the system clock then change the HSE state (ex. disable it).  * @note   The HSE is stopped by hardware when entering STOP and STANDBY modes.    * @note   This function reset the CSSON bit, so if the Clock security system(CSS)  *         was previously enabled you have to enable it again after calling this  *         function.      * @param  RCC_HSE: specifies the new state of the HSE.  *          This parameter can be one of the following values:  *            @arg RCC_HSE_OFF: turn OFF the HSE oscillator, HSERDY flag goes low after  *                              6 HSE oscillator clock cycles.  *            @arg RCC_HSE_ON: turn ON the HSE oscillator  *            @arg RCC_HSE_Bypass: HSE oscillator bypassed with external clock  * @retval None  */void RCC_HSEConfig(uint8_t RCC_HSE){  /* Check the parameters */  assert_param(IS_RCC_HSE(RCC_HSE));  /* Reset HSEON and HSEBYP bits before configuring the HSE ------------------*/  *(__IO uint8_t *) CR_BYTE3_ADDRESS = RCC_HSE_OFF;  /* Set the new HSE configuration -------------------------------------------*/  *(__IO uint8_t *) CR_BYTE3_ADDRESS = RCC_HSE;}/**  * @brief  Waits for HSE start-up.  * @note   This functions waits on HSERDY flag to be set and return SUCCESS if   *         this flag is set, otherwise returns ERROR if the timeout is reached   *         and this flag is not set. The timeout value is defined by the constant  *         HSE_STARTUP_TIMEOUT in stm32f4xx.h file. You can tailor it depending  *         on the HSE crystal used in your application.   * @param  None  * @retval An ErrorStatus enumeration value:  *          - SUCCESS: HSE oscillator is stable and ready to use  *          - ERROR: HSE oscillator not yet ready  */ErrorStatus RCC_WaitForHSEStartUp(void){  __IO uint32_t startupcounter = 0;  ErrorStatus status = ERROR;  FlagStatus hsestatus = RESET;  /* Wait till HSE is ready and if Time out is reached exit */  do  {    hsestatus = RCC_GetFlagStatus(RCC_FLAG_HSERDY);    startupcounter++;  } while((startupcounter != HSE_STARTUP_TIMEOUT) && (hsestatus == RESET));  if (RCC_GetFlagStatus(RCC_FLAG_HSERDY) != RESET)  {    status = SUCCESS;  }  else  {    status = ERROR;  }  return (status);}Regards,Danish

[neoirto]

Posted on April 28, 2016 at 21:38

Great, tx again Danish!

🙂